Bug 107455
| Summary: | vncviewer connect to Fedora Test 3 vnc server 4.0-0.beta4.3 freezes | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Harvey Modlin <harvey> |
| Component: | vnc | Assignee: | Tim Waugh <twaugh> |
| Status: | CLOSED ERRATA | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | hobnobherman, nico.bdav, rowan |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-11-19 13:53:40 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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]# ----------------------------------------- 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. 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.) 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? 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! To do with the mouse pointer changing shape perhaps? You could run the server with: -log '*:stderr:100' to get maximum logging output. I think this is to do with zero-sized cursors. *** Bug 107536 has been marked as a duplicate of this bug. *** 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. *** Bug 109699 has been marked as a duplicate of this bug. *** 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. 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? This update has now been released. |
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: