vncviewer -listen allows connections from UltraVNC SC clients, but doesn't display the window

[D B]

Package: xvnc4viewer
Version: 4.1.1+xorg1.0.2-0ubuntu4

I use UltraVNC-based SingleClick to support windows users: http://www.uvnc.com/pchelpware/creator/index.html

I've created a remote support application using their tool (http://www.uvnc.com/pchelpware/creator/index.html) and have used it for over a year to display Windows users desktops on my Ubuntu box. My regular motion is to run "vncviewer -listen" via terminal and then have the windows users connect to me. Up until Gutsy and the new xvnc4viewer version, this worked wonderfully and I'd call this a regression.

Now, I can still listen for people who use other VNC servers such as the UltraVNC server full edition, but not from SC. After some further perusing into the problem, I have a hunch it may be related to the RFB version of the server? The feedback I get back at a terminal for a working connection is as follows:
Mon Jul 2 14:25:18 2007
 CConn: Accepted connection from 192.168.2.197::3707
 CConnection: Server supports RFB protocol version 3.6
 CConnection: Using RFB protocol version 3.3

Mon Jul 2 14:25:20 2007
 TXImage: Using default colormap and visual, TrueColor, depth 24.
 CConn: Using pixel format depth 6 (8bpp) rgb222
 CConn: Using ZRLE encoding

Mon Jul 2 14:25:21 2007
 CConn: Throughput 20085 kbit/s - changing to hextile encoding
 CConn: Throughput 20085 kbit/s - changing to full colour
 CConn: Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn: Using hextile encoding

Mon Jul 2 14:25:36 2007
 main: End of stream

And for the UltraVNC SC server (which worked in the old vncviewer in feisty), I get:
Mon Jul 2 14:21:22 2007
 CConn: Accepted connection from 72.54.229.147::51545
 CConnection: Server supports RFB protocol version 3.16
 CConnection: Using RFB protocol version 3.8

Mon Jul 2 14:21:44 2007
 main: End of stream

In this case, I made the end of stream happen by ctrl+c. It just sits and waits for a long long time. I've tried using hextile as the PreferredEncoding, but that doesn't seem to help either.

[Alexsandro Haag (alexsandro-haag)]

Hello.
I too have this problem.

[Alwin T. (alwint)]

I also have this problem.
You could use xtightvnc instead. This one works.
Open a terminal and type: xtightvnc -listen

[D B (eburner)]

albuntu: for the record, it's 'xtightvncviewer -listen' and that totally does not work with UltraVNC's SC software in Gutsy.

In Feisty, yes. In Gutsy, nope. Thanks for trying though.

[Alwin T. (alwint)]

You'r right. I forgot the viewer... :-)
I tried it yeasterday again. When my brother connects with UltraVNC SC everything works fine. But when a freind of mine trys to connect with (with the same client) I also get an error.
Thats very strange.

[D B (eburner)]

Figured i'd share the comment from the duplicate bug: https://bugs.launchpad.net/ubuntu/+source/libvncserver/+bug/158798

If you do "sudo apt-get remove xvnc4viewer" (which also removes ubuntu-desktop unfortunately), then all is well again as the command xvncviewer will use the old version that worked.

[jac0b (jacbrooks)]

The above solution worked for me also.

[Victor Vargas (kamus)]

same here and works for me too : )

[Michael Heča (orgoj)]

Same error in 8.10

xvnc4viewer -listen 53755

VNC Viewer Free Edition 4.1.1 for X - built Apr 16 2008 13:02:40
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.

Mon Nov 3 21:57:00 2008
 main: Listening on port 53755

Mon Nov 3 21:57:06 2008
 CConn: Accepted connection from 192.168.1.65::2750
 CConnection: Server supports RFB protocol version 3.16
 CConnection: Using RFB protocol version 3.8

Mon Nov 3 21:57:41 2008
 main: End of stream
^C
Mon Nov 3 21:57:45 2008
 main: CleanupSignalHandler called

[Michael Heča (orgoj)]

Temporary solution is use binnary from http://www.karlrunge.com/x11vnc/ssvnc.html, working fine.

[exactt (giesbert)]

same problem here on latest intrepid amd64. was working before on hardy without problems.

[jptechnical (jptechnical)]

Tried the binaries for enhanced xtightvncviewer, unfortunately the scroll bars only work one way, but that was the case with the repo version as well. When I tried Intrepid I found that xtightvncviewer would not work listening either... which forced me back to hardy. So far, the only vnc viewer for linux I have tried that works in -listen is xtightvncviewer and it is IMHO more buggy than xvnc4viewer, and I need to test again to be sure but I didn't find anything that worked in 8.10.

[exactt (giesbert)]

@jptechnical: use the vncviewer mentioned here https://bugs.launchpad.net/ubuntu/+source/tightvnc/+bug/123631/comments/9 to make it work in intrepid.
for scrolling in the other direction use the right mouse button...

[lumbricus (lumbricus)]

The temporary solution suggested by orgoj in comment #9 is working for me, thanks!
It was quite easy to install (althought my first impression of the website was different). I just downloaded this file:

http://downloads.sourceforge.net/ssvnc/ssvnc_unix_only-1.0.22.tar.gz

...extracted it to something like /usr/local/bin and made the symlinks as suggested in the README:

     cd /usr/local/bin
     ln -s ssvnc/bin/{s,t}* .

and then 'tightvncviewer -listen' is doing it's job (Ubuntu 8.10).

[unggnu (unggnu)]

Still an issue in Karmic and also xvnc4viewer is affected.

[scottuss (scottuss)]

Yes, I can confirm that this bug is present in Karmic. Does anyone know what's happening with this?

I'll try the workaround listed above

[unggnu (unggnu)]

From the UltraVNC forum:
"sc is build with the old rfb protocol and use some non official rfb numbers.
( The whole thing was made before the rfb 3.4 was out)

If not using a ultravnc viewer, the viewer should tell he support 3.3 else
the server get confused and connection fails."

[David Rahrer (david-rahrer)]

I'm on Karmic with the same issue. Commenting to subscribe and hopefully gain some solution.

[RL (labedra)]

any update on this fix ? I'm having the same problem, any work around available ?
Thanks

[Diego Nartallo (dnartallo)]

Same problem.
Karmic
2.6.31-15-generic

xtightvncviewer and xvnc4viewer

[Jurgis Pralgauskis (jurgis-pralgauskis)]

people report that ssvnc might help as workaround

http://ubuntuforums.org/showpost.php?p=8299617&postcount=118

[scottuss (scottuss)]

Any more information about this?

My current "workaround" is having a laptop with Hardy running on it, ideally I want to upgrade to Karmic or Fedora 12, something which I can't do right now because only the Hardy version of tightvnc viewer will work with SC.

[aamonster (aamonster)]

Solved: instead of buggy sc created 7zip sfx installer archive with contains winvnc.exe + batch file to run it. The same functionality, but size ~600k.

[Dan Stieneke (dan-stieneke)]

Single-click using RealVNC 4.1

aamonster is right, that's how I've been doing it, but here's the details:

1) Place the following files into the same directory:
  * 7zr.exe (from the 7zip extras file @ http://sourceforge.net/projects/sevenzip/files/7-Zip/4.65/7z465_extra.7z/download)
  * 7zS.sfx (from the same place. Optionally UPX compress this file)
  * winvnc4.exe (from http://realvnc.com/products/free/4.1/download.html)
  * MakeSC.cmd as shown here
==============Begin MakeSC.cmd==============================
set exeFILE=NewSingleClick.exe
set clean=1
set zFILE=NewSC.7z
set confFILE=config.txt

echo ;!@Install@!UTF-8! > %confFILE%
echo ExecuteFile="go.bat" >> %confFILE%
echo ;!@InstallEnd@! >> %confFILE%

7zr a %zFILE% winvnc4.exe go.bat -m0=BCJ2 -m1=LZMA:d25:fb255 -m2=LZMA:d19 -m3=LZMA:d19 -mb0:1 -mb0s1:2 -mb0s2:3 -mx
copy /b 7zS.sfx + %confFILE% + %zFILE% %exeFILE%
if "%clean%"=="1" (
 del %zFILE%
 del %confFILE%
)
==============End MakeSC.cmd==============================
  * go.bat as shown here
==============Begin go.bat==============================
:: Must use start because winvnc4.exe does NOT return...
:: /B = don't start a separate CMD window
@echo off
start /b winvnc4.exe > nul
echo This program starts a "standalone" version of winvnc4.
echo It may fail if you have winvnc4 installed and running as a service.

goto SkipSingleConnection
set HOST=192.168.31.23
:: There needs to be a delay between the 1st call to winvnc4 and the 2nd, either via menu or ping
ping localhost -n 3 > nul
goto CONNECT
:SkipSingleConnection

echo.
echo After the green/blue/red on white "Vnc" icon appears in your taskbar,
echo choose one of the following:
echo.
echo 1 - Bob's machine
echo 2 - Joe's machine
echo.
set /p MACHINE=Enter the number representing the target machine:
goto Machine%MACHINE%
:Machine1
set HOST=192.168.1.2
goto CONNECT
:Machine2
set HOST=joe.example.com
goto CONNECT
:CONNECT
echo Attempting to connect to %HOST%
winvnc4.exe -connect %HOST% > nul

echo.
echo **********************************************
echo Close this windows to stop sharing your screen
echo **********************************************
echo.
title ***** Close this window to stop sharing your screen *****</verbatim>
==============Begin go.bat==============================

2) Modify MakeSC.cmd and go.bat as appropriate:
  a. set IP addresses
  b. change exeFILE to the preferred name of the final file
  c. set clean to 1 to delete temporary files, anything else to leave them in place
3) Run MakeNewSC.cmd
4) Run your new "NewSingleClick.exe". If you UPX'd the .sfx, it should be under 300K

[Evan Carroll (evancarroll)]

two bug reports upstream for this already.
http://sourceforge.net/tracker/?func=detail&aid=1737746&group_id=14067&atid=114067
http://sourceforge.net/tracker/?func=detail&aid=2959724&group_id=14067&atid=114067

[Evan Carroll (evancarroll)]

I just wanted to buzz back. Use `ssvnc` it has the same syntax for `-listen`, but works with RHB 3.8, and opens a Window.

[Evan Carroll (evancarroll)]

Actually, svnc doesn't use 3.8

Proto: RFB 003.016

Setting RFB version to 3.3 for UltraVNC Single Click.

Connected to RFB server, using protocol version 3.3
Security-Type: 1 (rfbSecTypeNone) Latency: 4.53 ms
No authentication needed

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Q (thread13)]

Hi, at least in my case the problem was that the "SingleClick" VNC server reported the protocol version 3.16 and the client's top version was the infamous 3.8 ; unfortunately, the client thinks that 3.8 is the maximum version that would be available ever and behaves (in)appropriately.

In my case the solution was fixing the code to use protocol version 3.3 when uncertain and using "hextile" for the encoding parameter ( i.e. replacing ">= 8" to "== 8" in the file 'rfbproto.c' at line 241 ) :

1.

sudo apt-get install build-essential xutils-dev # and may be sth else; basically you'll need make & gcc
sudo apt-get build-dep xtightvncviewer

2.
wget http://www.tightvnc.com/download/1.3.10/tightvnc-1.3.10_unixsrc.tar.gz
tar xzvf tightvnc-1.3.10_unixsrc.tar.gz

patch -p0 <rfbproto.patch # see attached

cd vnc_unixsrc/libvncauth && xmkmf && make
cd ../vncviewer && xmkmf && make

3.

./vncviewer -listen -encoding "hextile" # should be done by now

4. notes:

(a) should you have any problems with applying the patch file, you may simply edit the file 'rfbproto.c' and replace ">= 8" comparison near line 241 with a simple check for "== 8" ;

(b) there are two more ">= 8" entries in the protocol file, I didn't explore that, as the listen mode was all I wanted .

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "change "server_minor >= 8" to "server_minor == 8" at line 241" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]