-listen hangs after accepting a connection

Bug #172633 reported by Darren Warner
2
Affects Status Importance Assigned to Milestone
vnc (Ubuntu)
New
Undecided
Unassigned

Bug Description

Since upgrading to gutsy, vncviewer -listen fails to pop up a window after accepting a connection.

Here's the command line output:

warnerd@washington:~$ vncviewer -log '*:stderr:100' -listen

VNC Viewer Free Edition 4.1.1 for X - built Sep 10 2007 17:17:04
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.

Wed Nov 28 11:21:43 2007
 Config: set listen(Bool) to 1
 main: Listening on port 5500

Wed Nov 28 11:21:47 2007
 CConn: Accepted connection from 192.168.6.4::1343
 CConnection: reading protocol version
 CConnection: Server supports RFB protocol version 3.16
 CConnection: Using RFB protocol version 3.8
 CConnection: processing security types message

I can't seem to get any useful information from GDB about where it's hanging as SIGINT is getting passed to vnc (there have been some reports about this being a kernel 2.6 problem).

The problem has been reports by several people (see http://ubuntuforums.org/showthread.php?t=299489&page=6), but I haven't seen it in launchpad yet.

Revision history for this message
David Bott (david-bott) wrote :

Not an expert in VNC at all, but I believe the problem may be with the version of RFB in vnc. Note the version of RFB in the first connection (a successful connection) vs. the 2nd connection (unsuccessful connection using the UltraVNC single-click application):

[code]dbott@gutsy:~$ vncviewer -listen

VNC Viewer Free Edition 4.1.1 for X - built Sep 10 2007 17:17:04
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.

Wed Nov 28 19:01:26 2007
 main: Listening on port 5500

Wed Nov 28 19:06:37 2007
 CConn: Accepted connection from 69.49.xxx.yyy::62000
 CConnection: Server supports RFB protocol version 3.6
 CConnection: Using RFB protocol version 3.3

Wed Nov 28 19:06:38 2007
 TXImage: Using default colormap and visual, TrueColor, depth 24.
 CConn: Using pixel format depth 6 (8bpp) rgb222
 CConn: Using ZRLE encoding
 CConn: Throughput 11900 kbit/s - changing to hextile encoding
 CConn: Throughput 11900 kbit/s - changing to full colour
 CConn: Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn: Using hextile encoding

Wed Nov 28 19:10:57 2007
 CConn: Accepted connection from 69.49.xxx.yyy::62008
 CConnection: Server supports RFB protocol version 3.16
 CConnection: Using RFB protocol version 3.8

Wed Nov 28 19:12:00 2007
 main: End of stream[/code]

More details & screenshots here:
http://ubuntuforums.org/showthread.php?p=3857208#post3857208

-Dave

Revision history for this message
Darren Warner (launchpad-dazwin) wrote :

I hacked ConnParams::readVersion() to always assume "RFB 003.003" is sent by the server and the problem goes away (the viewer window appears). This should confirm Dave's comment above about it being an RFB version problem.

Unfortunately, this also means the bug actually lies in UltraVNC SingleClick (I used v20.3, which is based on RC23 according to the ultravnc web-site), which sends "RFB 003.016" as a version string.

I'm looking at RFB for the first time also, so maybe someone can confirm this?

Revision history for this message
Darren Warner (launchpad-dazwin) wrote :

Sorry, I reported this against the wrong package. After finding a thread about this problem on the UltraVNC forums (http://forum.ultravnc.info/viewtopic.php?t=10451), I found the same bug report filed against vnc4.

Revision history for this message
David Bott (david-bott) wrote :

For those that stumble across this bug/thread, Darren has posted a good workaround in this thread (post #66):

http://ubuntuforums.org/showthread.php?p=3858988#post3858988

-Dave

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.