Red Hat Bugzilla – Bug 102213
realvnc doesn't have some of the functionality that tightvnc had (esp. -via)
Last modified: 2007-04-18 12:56:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131
Description of problem:
RealVNC provides some useful advantages (notably better speed, at least in
perception), but from a straight translation from tightvnc we lose some
The biggest one was support for -via, which automatically set up the SSH tunnel
Yes, you can still use RealVNC by setting up the tunnel yourself, but I found
users much more comfortable with -via.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. vncviewer -via gateway internal:1
Actual Results: Syntax error for the new vncviewer
Expected Results: Connection to a machine name internal's VNC server, via an
ssh tunnel through the machine 'gateway'.
I'm calling this a bug, not an enhancement request, because it's a loss of
functionality as compared to previous releases. It's not a drop in replacement.
Please try 4.0-0.beta3.9, which provides a -via option. It will appear in
rawhide in the next few days.
I have tried the latest rawhide version, and it doesn't correctly handle the
case of using an intermediate gateway to access the destination machine:
In the case of "vncviewer -via gateway internalhost:1", it executed the
following ssh command:
/usr/bin/ssh -f -L 5598:localhost:5901 gateway sleep 20
where I would have expected it to run:
/usr/bin/ssh -f -L 5598:internalhost:5901 gateway sleep 20
(note the use of localhost as opposed to internalhost).
At many sites, the user will not have the capability to run a VNC server on the
In the vnc-via patch, the SSH tunnelling setup shouldn't hardcode localhost.
The algorithm should be "if a remote host is specified in the VNC server
argument, use that hostname, otherwise use localhost".
I think the current patch does the right thing now.
I agree. Things are as on the old VNC, in this respect.