summary [was: vnc and security]

W. Brian Blevins brian.blevins "at"
Tue, 19 Jun 2001 13:59:09 +0000


> Date: Mon, 18 Jun 2001 12:05:41 -0600
> From: Jeff Walker <jwalker "at">
> Subject: summary [was: vnc and security]
> First of all, thanks for the help, I didn't really find an acceptable
> solution, but here is what I found.
> - -Seems like the Tridia version of the viewer seemed to have a problem taking
> the "-encodings" flag, but the AT&T version did fine.

What exactly was the problem with the Tridia viewer?  I have tested it
extensively, including reviewing server logs to get an idea of the level
of compression afforded cersus CPU time used.  I'm not aware of any
problem with the "-encodings" parameter.

> - -Looks like over ssh, zlib was the best encoding to use (kinda strange,
> since I had ssh compression on [low compression])

To my knowledge, the AT&T viewers and servers do not support zlib.  If you
specified zlib to an AT&T vncviewer, I would guess it would be ignored,
resulting the vncviewer default encoding, hextile.

If you specified zlib to a Tridia viewer when connecting to an AT&T server,
you probably got some type of unknown encoding error in the server logs,
because the Tridia vncviewer would have sent the zlib encoding request to
the AT&T server, which would not have been able to support it.  In this
case you may have gotten the VNC server or protocol default encoding, which
is *raw*.

A thorough review of the server logs should indicate precisely which
encodings are rejected and which one is actually used for each connection.
In addition, the Unix based servers have some interesting compression and
CPU time statistics output to the log file when each connection closes.

Thanks for the feedback!

TridiaVNC, the cross-platform, open source, remote control solution.   and
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at"
See also: