Bugzilla – Bug 390468
VNC - corrupted image when connecting from RealVNC on Windows, connection reset by peer (10054) error after 2 seconds
Last modified: 2008-12-31 02:15:04 UTC
Created attachment 215309 [details] Corrupted screen after few redraws Hi, I found that TightVNC server in OpenSUSE 11 is unable to serve client connections from latest RealVNC (4.1.2). When I try that, first screen is ok (grey pattern), but when Kdm is loading and screen starts to refresh, it starts to corrupt itself (see attached image). After about 1 second vnc viewer closes and message box appears with message "Connection reset by peer (10054)". If I try to connect to OpenSUSE 11 from another machine with OpenSUSE 10.3 (with Krdc), it's working ok. If I try to connect from Windows XP (with VNC 4.1.2) to OpenSUSE 10.3, it's working perfectly too. My xinetd configuration: service vnc1 { socket_type = stream protocol = tcp wait = no user = nobody server = /usr/bin/Xvnc server_args = -inetd -once -query localhost -geometry 1024x768 -depth 16 type = UNLISTED port = 5901 } Thank you, Petr
*** This bug has been marked as a duplicate of bug 385677 ***
I don't know if bug 385677 is really solved, but this definetely not. I upgraded my OpenSUSE 11 to RC1 and nothing has changed. Connection from VNC still not working, same corrupted screen after connect and same connection fail after few seconds. I also tried never version from OpenSuse Factory (xorg-x11-Xvnc-7.3-108.1) and again nothing new.
And log from xinetd.log: 08/5/31@09:36:54: START: vnc1 from=10.41.137.110 08/5/31@09:36:58: EXIT: vnc1 signal=6 duration=4(sec) 08/5/31@09:39:23: START: vnc1 from=10.41.137.110 08/5/31@09:39:28: EXIT: vnc1 signal=6 duration=5(sec)
Which RealVNC (4.1.2) client are you using? I can only test Linux clients.
It's from here http://www.realvnc.com/cgi-bin/download.cgi. I tried download client for Linux and compile that under OpenSUSE 10.3 and it's working fine. But I need to connect to linux machine from windows also :( And I don't know about another client then RealVNC.
And I don't have Window available for testing. :-( Please reopen, once you can find a Linux VNC client with this issue. Thanks.
I have found a workaround. If I try to use RealVNC from Windows, there is checked box "Auto Select" on top left corner as default value and that is the problem. Real VNC always tries to use "Full(all available colors)" even lower value is selected. If I uncheck that box and I select lower color depth, it's working. More details: If I try to connect from RealVnc on Win, it opens Xvnc with this depth and color setting and crashes: 22/05/2008 11:22:54 16 bpp, depth 16, little endian 22/05/2008 11:22:54 true colour: max r 31 g 63 b 31, shift r 11 g 5 b 0 If I try to connect from RealVnc on Win with only 256 colors, it opens Xvnc with this depth and color setting and it is working: 22/05/2008 12:11:45 8 bpp, depth 8 22/05/2008 12:11:45 uses a colour map (not true colour). Less color settings are working too.
I also tried to force linux client to use that faulty setting: 22/05/2008 11:22:54 16 bpp, depth 16, little endian 22/05/2008 11:22:54 true colour: max r 31 g 63 b 31, shift r 11 g 5 b 0 , but I failed. I don't know how. I really think, that bug is in vncserver in handling this depth and pixel settings (which is regrettably the default setting in Win RealVNC). I also realized, that encoding has no influence. I also attached log with backtrace, if it helps. If my inquiry is not enough to found this bug without having Windows available, feel free to close this bug again :)
Created attachment 219610 [details] Failed connection with "Full(all available colours)" setting
Xvnc is started with 16bpp color depth. See /etc/xinet.d/vnc. Maybe you can find a color depth (try with 24bpp), which makes your Windows VNC client happy.
Now I am able to connect from Windows, as I wrote above, but a lot of people is using vncviewer on windows side and they will not. I think, that somebody should take care of this.
*** Bug 402219 has been marked as a duplicate of this bug. ***
How can this bug be "resolved"? While it is true that using "-depth 24" solves the problem, it is not a matter of "finding a color depth which makes ones Windows VNC client happy", since it is not the windows client that crashes! Also, there are default definitions in /etc/xinetd.d/vnc which would crash Xvnc as well.
Same Problem here, have to be put on the list ! Michael
To further clarify problem behaviour, with server OpenSUSE 11.0-GM XVnc 7.3-110.2 and client RealVNC 4.1.2 (windows x86): - VNC server set to 16bpp, RealVNC displays grey checkerboard garbage and bombs immediately when set to "Auto/ZRLE/Full (all) colours". Either Xvnc or RealVNC are crashing; I'm guessing it's Xvnc? - VNC server set to 24bpp, RealVNC behaves correctly at "Auto/ZRLE/Full (all) colours" - VNC server set to 16bpp, RealVNC works correctly when set to "Manual/*/Medium (or below) colourdepth". Note RealVNC offers no facility to select 16 bit colour, only 8-bit (256 colour) and below depth options are available. So, there seems to be no way to use Xvnc at 16-bit depth. 24-bit depth is fine for high speed LANs but a bandwidth hog for more restricted connections. Question: In the incorrect behaviour scenarios above, I want to confirm whether RealVNC (client) or Xvnc (server) are falling over. If Xvnc is started by the system, how do I see its output/logs? nb. Having examined the "duplicates" of this bug, I am not convinced; it seems that the duplicates are different problems. Seb :)
i tried with 11.1 RC2: 16 bit depth, works for a short time, crash (sometimes at gdm, sometimes later) 24, crash instantly so the workaround is not working anymore ... reopen
i have to correct myself. vnc is not crashing, it seems that it's "just" resetting the connection. If you use vnc the way it's in yast (with kdm/gdm login), this will lead to a reset of the connection, which looks like it's crashed. If you use vnc the good way and have a persistent desktop you can reconnect and it will still work. So the vncserver is not crashing.
> VNC - corrupted image when connecting from RealVNC on Windows This is handled upstream. http://sourceforge.net/tracker/index.php?func=detail&aid=2020401&group_id=48178&atid=452220 > connection reset by peer (10054) error after 2 seconds Duplicate. *** This bug has been marked as a duplicate of bug 441935 ***
This connection reset is definitely a bug in the vnc server, and it's not just limited to a single client on a single OS. I get the same behavior when trying to connect from Win2k via UltraVNC and from Ubuntu 8.10 running any of the available clients. It also exhibits the same behavior when trying to connect over http port 58xx using the java applet client that shipped with the server. The kdm (KDE3) login screen isn't corrupted when connecting via the UltraVNC client, but is corrupted using the java applet. But the both have the connection reset immediately upon completion of the login. It DOES work connecting from Debian Etch using Krdc (tightvnc). I saw identical behavior in openSUSE 11.0 about 6 months ago, but that eventually got fixed by one or more of the updates, so it's very disheartening to see it reappear in 11.1
Still this is a duplicate. The update is not available yet. *** This bug has been marked as a duplicate of bug 441935 ***