Vino not accepting incoming connection to more than a single desktop session when the "network_interfaces=lo" option is set

Bug #707705 reported by Etienne Goyer on 2011-01-25
This bug affects 1 person
Affects Status Importance Assigned to Milestone
vino (Ubuntu)

Bug Description

Binary package hint: vino

On lucid, when you set the /desktop/gnome/remote_access/network_interfaces gconf key to "lo", Vino will accept VNC connections only for the first desktop session. If you switch user, opening a new session as a different one, it is impossible to connect to that session. It works as expected when the network_interfaces gconf key is not set.

= Step to reproduce =

1. On the target machine, open a session as one user, then switch to a second user.

2. From another machine, witness that you can cannot connect to both session by VNC:

    $ vncviewer target:0 # VNC client screen remain black (session is locked), but connection is possible
    $ vncviewer target:1 # Connection ok

3. On the target machine, set the /desktop/gnome/remote_access/network_interface gconf key to default to "lo". I think you need to reboot the machine at that point, as it seems that Vino continue to accept connection on non-lo interfaces (but that is not german to this bug).

4. Try to connect remotely using ssh tunneling:

    $ vncviewer -via target localhost:0 # VNC client screen remain black (session is locked), but connection otherwise work
    $ vncviewer -via target localhost:1 # Connection is refused

= Expected behavior =

Vino should allow incoming connection to the current foreground session, whether directly or through an ssh tunnel when network_interfaces is set to "lo".

vino package is version 2.28.2-0ubuntu2.

I did the following test:

1. Log in as user1.

2. Switch session to user2.

3. Check with "netstat -alp --inet". Notice that only the vino-server of user1 is listening, on port 5900.

4. In user2's session, kill the vino-server process.

5. Manually run /usr/lib/vino/vino-server on the console. On stdout, we can see that it tries to bind to port 5900 (see attached output).

I guess that, in the above example, user2's vino-server should be trying to bind to port 5901. Correct?

I noticed that I forgot to attach the server output described above. Here it is.

description: updated

Tested on natty, confirmed it still has the bug (vino 2.32.1-0ubuntu1).

We've also go the same bug on Debian Squeeze, using vino 2.28.2-2., so it is not Ubuntu-specific.

Changed in vino:
importance: Unknown → Medium
status: Unknown → New
Changed in vino (Ubuntu):
importance: Undecided → Medium
Sebastien Bacher (seb128) wrote :

Thanks Etienne, let's see what upstream says about this one

Changed in vino (Ubuntu):
status: New → Triaged
Changed in vino (Ubuntu Lucid):
importance: Undecided → Low
status: New → Triaged
Changed in vino (Ubuntu):
assignee: nobody → Rodrigo Moya (rodrigo-moya)
status: Triaged → In Progress
Rodrigo Moya (rodrigo-moya) wrote :

I'm starting to think this is a permissions problem, but need more debugging

Rodrigo Moya (rodrigo-moya) wrote :

Ok, after some more debugging and talking with upstream, this bug seems to be related to some other problems there are in vino related to sockets handling, which as of today, don't seem to be too easy to fix. I'll keep trying to get a fix with upstream though

Changed in vino:
status: New → Confirmed
Rodrigo Moya (rodrigo-moya) wrote :

For now, I've found this patch ( in our package breaks vino for me, it makes it not possible to connect, either using "lo" or not as the network interface

Changed in vino (Ubuntu):
assignee: Rodrigo Moya (rodrigo-moya) → nobody
Torsten Spindler (tspindler) wrote :

I did some more testing on this problem, and it seems that even changing the port will not work with a network_interface specified. E.g. without network_interface set, and alternate_port set to 5995, I can connect to the server via 'vncviewer <target>:5995'.

After setting the network_interface to lo and using ssh tunneling, the connection attempt fails:

vncviewer -via ubuntu@<target> <target>:5995
ubuntu@<target>'s password:
channel 3: open failed: connect failed: Connection refused
vncviewer: VNC server closed connection

However, on <target> there is definitely a process listening on 5995:

tcp 0 0* LISTEN 1115/vino-server
tcp6 0 0 ::1:5995 :::* LISTEN 1115/vino-server

As an experiment, I connected to <target> via ssh -Y for X forwarding, and run vncviewer, which worked:

$ vncviewer localhost:5995
Connected to RFB server, using protocol version 3.7
No authentication needed
Desktop name "ubuntu@lucid"
VNC server default format:
  24 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using default colormap which is TrueColor. Pixel format:
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Same machine: preferring raw encoding

I then tried to use port forwarding with ssh, 'ssh -L 5995:<target>:5995 ubuntu@<target>', but this failed with:

$ vncviewer localhost:5995
vncviewer: VNC server closed connection

With that being unsuccessful, I tried a ssh/ppp tunnel, as a sort of VPN replacement:

$ sudo /usr/sbin/pppd updetach noauth silent nodeflate pty "/usr/bin/ssh root@<target> /usr/sbin/pppd nodetach notty noauth" ipparam vpn

Note that the root user needs to be enabled on <target> for the above to work. I could not figure out how to use sudo on <target> to get a pppd running. With this crutch, I could connect to both vino servers at different ports:

However, I could not get it running without the alternate_port specification.

This escalation can be closed. A work-around was provided, which satisfies the customer (thanks Torsten!). Vino in precise do not exhibit this bug. We can leave the public bug open, but I will close this one as "Won't Fix".

Changed in vino (Ubuntu):
status: In Progress → Won't Fix
status: Won't Fix → Confirmed
Changed in vino (Ubuntu Lucid):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.