Bug 107455 - vncviewer connect to Fedora Test 3 vnc server 4.0-0.beta4.3 freezes
vncviewer connect to Fedora Test 3 vnc server 4.0-0.beta4.3 freezes
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: vnc (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
David Lawrence
:
: 107536 109699 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-18 10:33 EDT by Harvey Modlin
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-11-19 08:53:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Harvey Modlin 2003-10-18 10:33:11 EDT
Description of problem:

VNC server running on Fedora Core test 3 loses connection with VNC viewer 
running on Windows XP over a LAN.

Version-Release number of selected component (if applicable):

VNC server is vnc-4.0-0.beta4.3.
VNC viewer is RealVNC Win32 VNCViewer 3.3.7

How reproducible:

Happens every time in Fedora Core test 3. However, the problem didn't exist in 
Fedora Core test 2 or RedHat 9.

Steps to Reproduce:
1. Telnet to Fedora (192.168.1.28). Login (root). Run "vncserver".
2. In Windows XP, run vncviewer 192.168.1.28:1
3. In vncviewer, launch a gnome-terminal session, mouse into the terminal 
window, and begin typing.
    
Actual results:

After a short while, as little as 1 second or as much as 20 minutes (but 
usually in under a minute), mouse cursor changes from pointer to a dot. On 
Windows screen if I click on the vnc button bar two times (to minimize 
vncviewer windows and then restore it, the first click will minimize vncviewer 
and the second click will cause it to disappear and the vncviewer task on 
Windows will be killed. However, the individual vncserver task on Fedora 
continues to run.

On Windows if I re-run "vncviewer 192.168.1.28:1" a new connection is 
established and I get to resume where I left off, but again only for 1 second 
to 15 minutes (usually less than one minute).

Expected results:

Just like in RedHat 9 or Fedora Core test 2, the vnc connection should work 
indefinitely. It shouldn't hang.

Additional info:
Comment 1 Harvey Modlin 2003-10-18 10:34:55 EDT
Command: vncserver
Result:
New 'hm28.skatedogs.com:1 (root)' desktop is hm28.skatedogs.com:1
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/hm28.skatedogs.com:1.log
-----------------------------------------

Command: ps -efwww|grep -i vnc
Result:
root      3947     1  0 07:21 pts/2    00:00:00 Xvnc :1 -desktop 
hm28.skatedogs.com:1 (root) -httpd /usr/share/vnc/classes -
auth /root/.Xauthority -geometry 1024x768 -depth 16 -rfbwait 30000 -
rfbauth /root/.vnc/passwd -rfbport 5901 -pn

-----------------------------------------
THEN, AFTER FAILURE AND RECONNECTION:
-----------------------------------------
Command: cat /root/.vnc/hm28.skatedogs.com:1.log
Result:
Xvnc version 4.0b4 - built Sep 19 2003 09:32:30
Underlying X server release 40300000, The XFree86 Project, Inc

Sat Oct 18 07:21:22 2003
 vncext:      VNC extension running!
 vncext:      Listening for VNC connections on port 5901
 vncext:      Listening for HTTP connections on port 5801
 vncext:      created VNC server for screen 0
error opening security policy file /usr/X11R6/lib/X11/xserver/SecurityPolicy
Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from 
list!
SESSION_MANAGER=local/hm28.skatedogs.com:/tmp/.ICE-unix/3955
AUDIT: Sat Oct 18 07:21:26 2003: 3947 Xvnc: client 3 rejected from local host
Window manager warning: Log level 32: could not find XKB extension.

Sat Oct 18 07:23:05 2003
 Connections: accepted: 192.168.1.2::1490
 SConnection: Client needs protocol version 3.3

Sat Oct 18 07:23:07 2003
 Client:      Server default pixel format depth 16 (16bpp) little-endian rgb565
 Client:      Client pixel format depth 8 (8bpp) bgr233

Sat Oct 18 07:23:08 2003
 Client:      Client pixel format depth 16 (16bpp) little-endian rgb565

Sat Oct 18 07:26:34 2003
 Connections: accepted: 192.168.1.2::1506
 SConnection: Client needs protocol version 3.3

Sat Oct 18 07:26:35 2003
 Client:      Server default pixel format depth 16 (16bpp) little-endian rgb565
 Connections: closed: 192.168.1.2::1490 (Non-shared connection requested)
 SMsgWriter:  framebuffer updates 275
 SMsgWriter:    hextile rects 581, bytes 1753464
 SMsgWriter:    ZRLE rects 2, bytes 79640
 SMsgWriter:    raw bytes equivalent 3829712, compression ratio 2.089195
 Client:      Client pixel format depth 8 (8bpp) bgr233

Sat Oct 18 07:26:36 2003
 Client:      Client pixel format depth 16 (16bpp) little-endian rgb565

Sat Oct 18 07:26:44 2003
 Connections: accepted: 192.168.1.2::1508
 SConnection: Client needs protocol version 3.3

Sat Oct 18 07:26:45 2003
 Client:      Server default pixel format depth 16 (16bpp) little-endian rgb565
 Connections: closed: 192.168.1.2::1506 (Non-shared connection requested)
 SMsgWriter:  framebuffer updates 10
 SMsgWriter:    hextile rects 11, bytes 934643
 SMsgWriter:    ZRLE rects 1, bytes 53977
 SMsgWriter:    raw bytes equivalent 2362288, compression ratio 2.389480
 Client:      Client pixel format depth 8 (8bpp) bgr233

Sat Oct 18 07:26:46 2003
 Client:      Client pixel format depth 16 (16bpp) little-endian rgb565

[root@hm28 root]# 
-----------------------------------------
Comment 2 Tim Waugh 2003-10-21 12:41:15 EDT
Weirdly, both Fedora Core test 2 and test 3 had the same version of VNC as far
as I can tell: 4.0-0.beta4.3.

If you tell the viewer to use a different encoding, something other than ZRLE,
does the problem go away?  You can use the F8 dialog to specify the encoding to use.
Comment 3 Harvey Modlin 2003-10-22 13:58:15 EDT
The problem occurs no matter what encodings (ZRLE, hextile, raw, etc), pixel 
depths (8, 16, etc), or geometries (800x600, etc). Today I tried something 
new. I connected from another Linux machine. Here is the result:

NO VNC CONNECTION PROBLEM IF...

a) VNC server 4.0-0.beta4.3 on Fedora Test 3; VNC viewer 3.3.3r2-47 on RH9.
b) VNC server 3.3.3r2-47 on RH9; RealVNC 3.3.7 viewer on Windows XP.

VNC CONNECTION PROBLEM ONLY IF...

c) VNC server 4.0-0.beta4.3 on Fedora Test 3; RealVNC 3.3.7 viewer on Windows 
XP.

The three computers (Fedora, RH9, Windows XP) are located within 2 meters, 
connected to one network hub, on same IP subnet.

So, forgetting for now the various parameters such as protocol, encoding, 
geometry, etc....

In Fedora, I log in via ssh 192.168.1.28 and type this command: vncserver

In Windows, I type :) this command: vncviewer 192.168.1.28:1

Then I click on the gnome menu start button (oops I meant the red fedora), 
press alt-F2 (the Run dialog), type "gnome-terminal", click on the "Run" 
button. So far so good. This proves that keyboard typing and mouse clicking 
are both possible. Finally, I type any key inside the gnome-terminal window 
and instantly my mouse cursor changes to a dot and further mouse and 
keyboarding is frozen in the vncviewer session. (All other Windows XP 
functionality remains, however.)

Comment 4 Harvey Modlin 2003-10-22 14:09:27 EDT
I tried another experiment and got a surprise. The problem I described above 
occurs with gnome-terminal and kate but not with xterm or kterm. Is that weird 
or what?
Comment 5 Harvey Modlin 2003-10-23 00:20:25 EDT
I tested again and found...
Disconnect occurs typing in kword, konsole, gnome-terminal.
Disconnect does NOT occur typing in xterm, uxterm, abiword.
It really, really is application sensitive!
Comment 6 Tim Waugh 2003-10-23 10:37:31 EDT
To do with the mouse pointer changing shape perhaps?
Comment 7 Tim Waugh 2003-11-07 23:24:51 EST
You could run the server with: -log '*:stderr:100'
to get maximum logging output.

I think this is to do with zero-sized cursors.
Comment 8 Tim Waugh 2003-11-08 09:05:17 EST
*** Bug 107536 has been marked as a duplicate of this bug. ***
Comment 9 Tim Waugh 2003-11-10 12:12:42 EST
ftp://people.redhat.com/twaugh/tmp/vnc-server-4.0-0.beta4.5.i386.rpm

is an experimental package containing what I hope is a fix for this
issue.  Feedback on whether it works for you would be great.
Comment 10 Tim Waugh 2003-11-10 21:14:07 EST
*** Bug 109699 has been marked as a duplicate of this bug. ***
Comment 11 Tim Waugh 2003-11-14 08:17:12 EST
Moved to:
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/1/i386/

Please verify that the problem is fixed in either 0.beta4.5 or
0.beta4.3.1.
Comment 12 Paul Hirst 2003-11-18 10:04:58 EST
I have tried the fix at
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/1/i386/
and it certinally solved the problem for me.

Is it likely to get moved from testing to updates any time?
Comment 13 Tim Waugh 2003-11-19 08:53:40 EST
This update has now been released.

Note You need to log in before you can comment on or make changes to this bug.