Re: Connecting to vino fails

["Daniel P. Berrange" <dan berrange com>]

On Wed, Sep 01, 2010 at 07:09:22PM +0200, Guido Günther wrote:
> Hi,
> using current git (but also 0.4.1) connectiong via gtk-vnc (either with
> gvncviewer or vinagre) to vino fails like this:
> 
> $ examples/gvncviewer --gtk-vnc-debug foo.local 
> 
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Init VncConnection=0x83001b8
> (lt-gvncviewer:15455): gtk-vnc-DEBUG: vncdisplaykeymap.c Using evdev keycode mapping
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Open host=grosser.local port=5900
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Open coroutine starting
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Started background coroutine
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Resolving host grosser.local 5900
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Trying one socket
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Socket pending
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Finally connected
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Emit main context 12
> (lt-gvncviewer:15455): gtk-vnc-DEBUG: vncdisplay.c Connected to VNC server
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Protocol initialization
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Server version: 3.7
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Using version: 3.7
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Possible auth 18
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Possible auth 1
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Emit main context 10
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Thinking about auth type 18
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Decided on auth type 18
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Waiting for auth type
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Choose auth 18
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Do TLS handshake
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Handshake was blocking
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Handshake was blocking
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Handshake was blocking
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Handshake was blocking
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Handshake done
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Completed TLS setup
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Got 1 subauths
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Got 1 subauths
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Possible sub-auth 1
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Emit main context 10
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Thinking about auth type 1
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Auth failed
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Doing final VNC cleanup
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Close VncConnection=0x83001b8
> (lt-gvncviewer:15455): gvnc-DEBUG: vncconnection.c Emit main context 14
> (lt-gvncviewer:15455): gtk-vnc-DEBUG: vncdisplay.c Disconnected from VNC server
> Connected to server
> Disconnected from server
> 
> Remove auth_tls from the preferred auths works around the issue:
> 
> diff --git a/src/vncdisplay.c b/src/vncdisplay.c
> index 9ef9841..96dbbdf 100644
> --- a/src/vncdisplay.c
> +++ b/src/vncdisplay.c
> @@ -1850,7 +1849,9 @@ static void vnc_display_init(VncDisplay *display)
>  	 * be the first listed
>  	 */
>  	priv->preferable_auths = g_slist_append (priv->preferable_auths, GUINT_TO_POINTER (VNC_CONNECTION_AUTH_VENCRYPT));
> +#if 0
>  	priv->preferable_auths = g_slist_append (priv->preferable_auths, GUINT_TO_POINTER (VNC_CONNECTION_AUTH_TLS));
> +#endif
>  
>  	/*
>  	 * Then stackable auth types in order of preference
> 
> Using other clients works as expected. Connectiong with gvncviewer to
> kvm also works fine too. Vino is 2.28.2.
> Any ideas what's causing this before I dig deeper?

The server initially offers 2 auth types in order 'TLS(18)',
'None(1)'. Most clients will choose 'none', since they don't
support TLS auth. GTK-VNC will choose 'TLS' since that's the
first reported one by the server.  The first phase of TLS
auth appears successful, and Vino then offers 'None' as a
sub-auth. This appears to fail which is rather odd :-)
Could be a bug in either Vino or GTK-VNC handling of the
'none' type when used as a sub-auth scheme

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|