TurboVNC Compatibility with Gnome's Vinagre

49 views
Skip to first unread message

Andrew

unread,
Jan 21, 2021, 5:16:54 PM1/21/21
to TurboVNC User Discussion/Support
I noticed that a TurboVNC server does not seem to be compatible with Gnome's Vinagre software. I've tried this on both RHEL7 and RHEL8 systems. I start a session with "vncserver -SecurityTypes none", but when I try to connect using Vinagre, I immediately get a "Connection Closed" error on the Vinagre client. In the VNC log, the connection is recognized, but the message "Connection reset by peer" is logged. Note I also tried a TigerVNC server with the same command as above and could connect using Vinagre with no issue. 

It's not really a big deal I was just wondering if this issue had come up before for anyone and if I'm missing a way to get Vinagre to connect to a TurboVNC session. I tried a number of different parameters on the server but was unsuccessful. 

DRC

unread,
Jan 21, 2021, 9:05:18 PM1/21/21
to turbovn...@googlegroups.com

Probably no one has tried it.  TurboVNC works best with our viewer, which has a lot better performance than Vinagre, but I will try to fix the compatibility issue if possible.

DRC

unread,
Jan 22, 2021, 2:32:32 PM1/22/21
to turbovn...@googlegroups.com
There are two issues at work:

1. Vinagre doesn't seem to have a correct implementation of VeNCrypt, so
as is the case with the TigerVNC Server, it is necessary to disable any
VeNCrypt security types in the TurboVNC Server. Passing '-securitytypes
vnc,otp,unixlogin' to /opt/TurboVNC/bin/vncserver or setting
$securityTypes = vnc,otp,unixlogin in ~/.vnc/turbovncserver.conf or
/etc/turbovncserver.conf accomplishes that.

2. When multi-threaded Tight encoding is enabled, the TurboVNC Server
uses the four zlib streams available for Tight encoding differently than
when multi-threaded Tight encoding is disabled. A properly-implemented
TightVNC-compatible viewer should be able to handle both use cases, but
apparently Vinagre doesn't have a correct implementation of Tight
decoding, so it only handles the single-threaded use case. Passing
-nomt to /opt/TurboVNC/bin/vncserver or setting $numThreads = 1 in
~/.vnc/turbovncserver.conf or /etc/turbovncserver.conf works around the
issue.

Also, I strongly recommend enabling "Use JPEG Compression." The
performance will suck otherwise.

On 1/21/21 4:16 PM, Andrew wrote:
> I noticed that a TurboVNC server does not seem to be compatible with
> Gnome's Vinagre <https://en.wikipedia.org/wiki/Vinagre> software. I've

Andrew

unread,
Jan 22, 2021, 6:15:35 PM1/22/21
to TurboVNC User Discussion/Support
Thank you so much for this workaround and the information behind why these parameters are necessary. 

I do prefer to use the Turbo viewer if possible, but came across this in a controlled environment where Vinagre was the only installed VNC client. 

Thank you again. 

Reply all
Reply to author
Forward
0 new messages