vinagre fails to connect

It seems vinagre can't connect to v3.3 or older clients!!! I've tried to connect to RealVNC and TightVNC servers and it always give up with connection to host was closed. It connects right away with another hardy heron machine.

This is essential to my work where I have to connect to hundreds of computers to help users so please fix this as soon as possible.

James, could you please paste here the output of xvnc4viewer with that machine?

Jonh Wendell <email address hidden> writes:

> James, could you please paste here the output of xvnc4viewer with that
> machine?

| $ xvnc4viewer localhost:5900
|
| VNC Viewer Free Edition 4.1.1 for X - built Sep 10 2007 17:17:04
| Copyright (C) 2002-2005 RealVNC Ltd.
| See http://www.realvnc.com for information on VNC.
|
| Wed Apr 2 18:27:43 2008
| CConn: connected to host localhost port 5900
|
| Wed Apr 2 18:27:44 2008
| CConnection: Server supports RFB protocol version 4.0
| CConnection: Using RFB protocol version 3.8
|
| Wed Apr 2 18:27:47 2008
| TXImage: Using default colormap and visual, TrueColor, depth 24.
| CConn: Using pixel format depth 6 (8bpp) rgb222
| CConn: Using ZRLE encoding
| CConn: Throughput 20000 kbit/s - changing to hextile encoding
| CConn: Throughput 20000 kbit/s - changing to full colour
| CConn: Using pixel format depth 24 (32bpp) little-endian rgb888
| CConn: Using hextile encoding
| zsh: exit 1 xvnc4viewer localhost:5900
| $

(The 'localhost' is because I'm ssh port forwarding to the machine which
is several networks away.)

--
James

OK, This issue has been fixed in gtk-vnc development version. The fix will be available in the next vinagre version.

(let's leave the Ubuntu task open until the fix reaches the repositories, which I assume will be Intrepid as gtk-vnc introduces so many changes (and hasn't even been officially released yet))

Hi, Emilio, I always get confused about fix commited vs released :)

Sure this is stuff for Hardy+1, I do not guarantee that Vinagre 0.5 will run fine with that new version of gtk-vnc.

I experience the same behavior when using vinagre "against" two different linux host, both running ubuntu gutsy.
It is also important to note that given a significant number of retries the connection will eventually succeed.
Using
ii vinagre 0.5.0-1 VNC client for the GNOME Desktop
on ubuntu hardy.

I am curious if this is going to be fixed for hardy release. Otherwise it would be quite ridiculous to have a default vnc client that is not even able to connect to the previous version of ubuntu...

Hey guys. Just an FYI this will not connect to a host running Leopard either. krdc connects just fine, but vinagre just quits saying it could not connect to the host. It finds it though when you browse.

I have just found a very weird thing :

1. Try to connect using vinagre a few times. I get "the connection was closed" every time.
2. I try to connect using vncviewer (from xtightvncviewer ) and this works fine.
3. I close vncviewer and get back to vinagre and try to connect again using vinagre. Now this also works every time.
4. WTF :) ?

Is this fix going to make into Hardy or Hardy.1?

If not, I think you should simply remove it. It doesn't really work.

Matthew Tighe wrote:
> Is this fix going to make into Hardy or Hardy.1?

Unfortunately it won't, as this requires a new version of gtk-vnc which we won't
introduce at this stage.

>
> If not, I think you should simply remove it. It doesn't really work.

I'm sorry it doesn't work for this case, but it works for others. Also, you can
install xvncviewer on your own, so I don't think we should change it as it's now
the official GNOME client and we should give it a chance and support it.

For Intrepid, it will be much better and won't have any regressions compared to
xvncviewer.

If a definitive fix will not make it to hardy, then at least vinagre should be demoted from the default vnc client position. I want to remind everybody that
this release is LTS and it would be very lame to ship something that is installed by default and by default it does not work.

Thank you.

IMHO, Ubuntu Hardy should come with gtk-vnc 0.3.5, and vinagre 0.5.1 with this patch: http://svn.gnome.org/viewvc/vinagre?view=revision&revision=273

Jonh,

I guess it's too late to update gtk-vnc at this point. RC is this Friday and final release next Thursday...
We already have vinagre 0.5.1, and that patch is only for debugging purposes? If so, it's not probably worth the risk at this point (without looking at the diff, svn.gnome.org isn't working well for me...).

Can't we backport a fix for this bug from the gtk-vnc hg repo?

Will gtk-vnc 0.3.5 fix this bug?
Soren, what's your opinion on updating gtk-vnc?

gtk-vnc 0.3.5 fixes this bug, along with other one related to wrong colors (bug #212504).

What I mean in my previous comment is: If you are going to update gtk-vnc to 0.3.5, you need to apply that patch in vinagre, in order to have debug stuff enabled. Having debug stuff enabled is mandatory!

Also, IMHO it's important to backport the patch indicated on bug #207205.

In short, 3 important bugs fixed.

status: confirmed

Similar issue here trying to MacOSX 10.5 while it work fine with
xtightvncviewer.

Raising importance to high as this makes Vinagre unusable in some cases and is a regression wrt xvncviewer.

Please, see bug 218667 where I request an exception to get an update for gtk-vnc fixing this bug. There's a link to my ppa which has the update, so please test it and comment on that bug.

Thanks

Connecting to a mac, updating gtk-vnc to the version in your ppa did change the error message to "Authentication method to host "xxx.xxx.xxx:5900" is unsupported. (30)", but did not solve the issue.
(I guess I did not need to reboot after applying the package).

But why does it work right after connecting with vncviewer ?
Connecting to a host with xtightvncviewer (which always works) triggers vinagre to also work for that target.

Hardy was released with this bug!
As mentioned above, it's unbelievable that a LTS release admits as default a program that won't connect even with the previous Ubuntu version.
That one can install another program later is not an excuse. Remember it's a default app, and as such people will usually try it before installing another one. This may be admissible to developers, but non-Power users won't always know what to do, and that greatly degenerates Ubuntu's image as "a desktop solution to Windows". Also remember that usually people will use it to talk to Windows and MacOS machines, not always Ubuntu of the latest version.

Definitely, a fix should be considered in Hardy, even if that means upgrading gtk-vnc. After all, there aren't that much packages which depend on it yet, Vinagre itself being the most expressive one.

I'd like to back up Xamusk's opinion on this.

Does anybody have a work-around for this, in the meantime?

I am able to replicate Nick Barcet's steps, and verify that the error message does in fact change to:

        Authentication method to host "192.168.1.108:5900" is unsupported. (30)

More informative, but vinagre is still broken for connecting to a mac, even after installing the svn versions of gtk-vnc and vinagre.

We still don't support this auth method (30). But I have made a patch that should work in cases where the server supports more than one auth type.

The patch:http://gtk-vnc.codemonkey.ws/hg/outgoing.hg/rev/e1b964facd65

Jonh Weldell:

That patch, applied to my svn/hg version of vinagre + gtk-vnc, did the trick!

Vinagre was able to connect to my OSX box without any further trouble.

Thanks for fixing that.

I don't know what the process for this is, but somebody in Ubuntu should really consider pushing this fix into a Hardy Heron update.

interim_descriptor wrote:
> I don't know what the process for this is, but somebody in Ubuntu should
> really consider pushing this fix into a Hardy Heron update.

I opened bug 218667 for updating gtk-vnc for Hardy, but it was too late and it
introduced some regressions so this won't probably hit hardy-updates
unfortunately. Unless we can backport a non-intrusive patch for them, without
updating gtk-vnc entirely.

I don't know what the process for this is, but somebody in Ubuntu should really consider pushing this fix into a Hardy Heron update.

.....

thanks for your interest on getting the issue fixed, I've opened an hardy task now

debdiff attached for hardy-proposed:

gtk-vnc (0.3.4-0ubuntu2) hardy-proposed; urgency=low

  * Cherry-pick fixes from upstream:
    - from_upstream_fix_crash_on_closing_connection_lp_207205.patch:
      + Fixes a crash when closing the connection on the middle of an
        update. LP: #207205.
    - from_upstream_fix_endianess_conversion_lp_212504.patch:
      + Fixes some big endian conversion bugs, causing wrong colors
        in Vinagre. LP: #212504.
    - from_upstream_fix_vinagre_connection_lp_206227.patch:
      + Fixes clients not being able to connect to some servers.
        LP: #206227.

 -- Emilio Pozuelo Monfort <email address hidden> Tue, 06 May 2008 11:25:00 +0200

0.3.5 synced to Intrepid, the SRU for hardy is on its way (see bug 206227)

Accepted into -proposed, please test and give feedback here

Version 0.3.4-ubuntu2 doesn't help the issue here, vinagre still gives the same "Connection to host "unattended@server" was closed." message:

$ dpkg -l | grep vnc
ii libgtk-vnc-1.0-0 0.3.4-0ubuntu2 A VNC viewer widget for GTK+ (runtime librar
ii python-gtk-vnc 0.3.4-0ubuntu2 A VNC viewer widget for GTK+ (python binding
ii xtightvncviewer 1.2.9-22 virtual network computing client software fo

Crispin,

Does it work as before then (i.e. no regressions?). That gtk-vnc update fixes two other issues, so if it doesn't introduce any regressions we will move it to hardy-updates, even if it doesn't fix this bug.

In as much as it didn't work before, and it still doesn't work in the same way, then Yes I suppose there aren't any regressions for me :-)

Reopening, since the current SRU did not fix it.

0.3.6 in Intrepid is supposed to fix this. Marking as fix committed for now as it's dep-waiting on libgtkglext

gtkglext promoted to main. Please reopen if there are still problems with building this.

What's the fix in 0.3.6? Can it be backported to hardy?

Martin Pitt wrote:
> gtkglext promoted to main. Please reopen if there are still problems
> with building this.
>
> What's the fix in 0.3.6? Can it be backported to hardy?

It was supposed to be
debian/patches/from_upstream_fix_vinagre_connection_lp_206227.patch (see comment 24)

Jonh, do you have a clue why it didn't work? The hg repo seems to be down right
now, so I can't check if there was more related commits...

With Intrepid, Connecting to a mac, I get "Authentication method to host "xxx.xxx.xxx:5900" is unsupported. (30)

Why not just drop vinagre ? It's broken since the beginning, never worked properly. It's presence in the stable releases (and in the LTS too !) is not justified.

Couldn't agree more. It's half made product which shouldn't be released when Terminal server client does the job.
There is still international keyboard support issue that makes it completely useless for non-english users.

It seems this problem repeats itself with every release. Here I am in Maverick and having the same problems as 2 years ago.

Anyone listens ?
Drop this c&@p from the default install.