vino-server doesn't accept IPv4 connections when "local only" is checked

[Jason]

Binary package hint: vino

I'm running Ubuntu Hardy. When vino-server is configured to listen only on local interfaces, it doesn't accept connections from IPv4 addresses. This means that "vncviewer localhost" will end up with connection refused.

Vino configurations:
jason@jason-laptop:~$ gconftool -a /desktop/gnome/remote_access
 authentication_methods = [none]
 lock_screen_on_disconnect = true
 use_alternative_port = false
 require_encryption = false
 view_only = false
 prompt_enabled = false
 icon_visibility = client
 vnc_password =
 enabled = true
 local_only = true
 alternative_port = 5900
 mailto =

Although it's possible to connect through an IPv6 ssh tunnel, I think it's not appropriate to reject IPv4 connections.

[Emilio Pozuelo Monfort (pochu)]

This is known upstream and will probably be fixed in 2.24

[elventear (elventear)]

Having the same problem. Is there a workaround for this issue? I have tried using SSH tunnels using IPv6 addresses explicitly but it doesn't work.

[Jason (jasonxh)]

elventear, to build the tunnel you should run something like this on your client side:

ssh -L 5910:[::1]:5900 <email address hidden>

Then you should be able to run "vncviewer localhost:10"

[lsomchai (lsomchai)]

I used tightvnc viewer on Windows XP connect to vino on Ubuntu and found the same problem.

Someone said that this problem may be fixed in version 2.24 but I do not want to upgrade my Ubuntu. So, I had solved this problem by install IPV6 support on my Windows XP and it work!!!.

[Andreas Henriksson (andreas-fatal)]

Patch now available at http://bugzilla.gnome.org/show_bug.cgi?id=403192
Not likely to be fixed in 2.24 which is due too soon according to upstream maintainer (also needs testing on BSD).

[mmail (mmailm)]

So, any possibility to have this problem fixed in Hardy?

* RANT MODE ON *
This is exactly the kind of bugs that drives me mad. This is not some strange problem in a strange function of a remote piece of code in a seldom used app. This is a big problem in the remote access tool of the most used free software desktop. How it is possible that it got into a STABLE release of Gnome AND Ubuntu without nobody noticing it? It is possible that nobody EVER tried a local connection to VNC? As Anybody ever TESTED it? It is not some super strange corner-case: tick local connections, try to connect, IT DOES'T WORK! And nearly a YEAR (form 2007 in Gnome Bugzilla) to have it fixed? Will somebody port the patch to 2.22 or 2.20? Probably not because it is not a new shiny feature and we must work on fast on our next HALF BACKED, STABLE new release!
Issue like this are the real problem of the Linux desktop. Sh*&87 bugs not meant to be here in the first time if just a little REAL test was done. Gnome and Kde are and have been full on this untested sh*776 pieces of code from ever in their STABLE releases. Even the explorer.exe of Win95 probably had less bugs than any version of Gnome panel+nautilus+control center ecc..
* RANT MODE OFF *

And please, excuse my bad english

[Jonh Wendell (wendell)]

go ahead and back to windows. thank you.

[Emilio Pozuelo Monfort (pochu)]

mmail wrote:
> * RANT MODE ON *
> This is exactly the kind of bugs that drives me mad.

This is exactly the kind of comments that will make people go away and do
something else.

[Jorge Pereira (jpereiran)]

Buddy,

if you want better quality and fast solution for solve the problems found in opensource! don't wait, just work! or following the hint of Jonh Wendell! back to windows and go ahead!

The patch available at http://bugzilla.gnome.org/show_bug.cgi?id=403192

Thank you!
[]s

[mmail (mmailm)]

This is exactly the kind of issues that make people go back to Windows.

I started using GNU/Linux 7 years ago and I have seen this kind of problems too many times, in too many distros. In desktop enviroments in particular. Bugs that simply should not have made into a stable release. Bugs that could be found even before an alpha release if just the developer/distro peoples tried to resize the screen, resize a panel, build and run the program on another machine, things like that. Simple basic tests.

I would like to discuss more on the matter but this is not a forum, so going back to the original question:
Will and update be released for Hardy?

[Sebastien Bacher (seb128)]

the number of people in the team is quite slow, most of those contributing are volunteers which give and hand when they want and there is over an hundred GNOME packages to work on in several distribution version, there is just lot of work, the bug could be fixed in hardy but it would require somebody working on the backport, there has not been a lot of user traction to get this one fixed so it's low on the stack, you are welcome to work on the update though

[Launchpad Janitor (janitor)]

This bug was fixed in the package vino - 2.25.91-0ubuntu1

---------------
vino (2.25.91-0ubuntu1) jaunty; urgency=low

  * New upstream release (LP: #330215)
    - Install autostart file in $sysconfdir/xgd/autostart. Usually you
      should pass the argument --sysconfdir=/etc to configure (or
      autogen.sh) script.
    - i18n related fixes.
    - Minor fixes. (LP: #196675, #228370, #237883, #289034)
    - Translations (ast, bg, ca, da, es, et, eu, hu, nl, or, pl, pt_BR,
      pt, ro, sv, th, vi, zh_HK, zh_TW)
  * Add Vcs-Bzr in debian/control.in
  * Re-generate debian/control

 -- Didier Roche <email address hidden> Mon, 16 Feb 2009 20:35:56 +0100

[Chris Fuller (cfuller415)]

workaround/trick:
I don't think this counts as a "workaround", since the end functionality doesn't have any caveats or limitations.

Set these gconf keys in /desktop/gnome/remote_access (I used gconf-editor):
   local_only to "false"
   network_interface to "lo"

Create the key(s) if they don't exist. If you need to create local_only (I did), be sure you create it as a boolean. Vino should listen on both ipv4 and ipv6 loopback interfaces now. I was able to restart it by simply killing vino and bringing up the remote desktop preferences dialog.

[Sean Cavanaugh (sean-e-cavanaugh)]

is this actually fixed? I did a yum update vino and it says there is nothing to update, I am running on Fedora 13 and this is till funding to the ipv6 only address (do a "lsof -i -P | grep -i "listen") and you can see its binding to the ipv6 only and not the ipv4... can someone link me to how to update vino correctly?

[deadlycheese (deadlycheese)]

I was able to fix this on Fedora by modifying the /etc/hosts file. See Bug 703009 (https://bugzilla.redhat.com/show_bug.cgi?id=703009).