Vino vnc connection refused post Ubuntu 11.10 upgrade

[bigbodytad]

Upon upgrading to 11.10 from 11.04, I am unable to connect via vnc using the vino vnc server. Nothing was changed in the configuration prior to the update. Tried to uninstall and reinstall the package or change the password, but still unable to connect. My VNC client says 'connection refused'

Vino:

Installed: 3.2.0-0ubuntu1
Candidate: 3.2.0-0ubuntu1
Version table:
*** 3.2.0-0ubuntu1 0
500 http://us.archive.ubuntu.com/ubuntu/ oneiric/main i386 Packages
100 /var/lib/dpig/status

[bigbodytad (bigbodytad)]

Oops the last line should read

100 /var/lib/dpkg/status

[arwenvaughan (arwenvaughan)]

I am having the same issue since upgrading to Ubuntu 11.10. I made sure that it is not a firewall or other connectivity issue. Vino appears to be running fine but I can not connect to it from outside my local computer. Is canonical recommending a different VNC server or is this a bug?

[Sebastien Bacher (seb128)]

> Is canonical recommending a different VNC server or is this a bug?

this is a bug, vino is working there on an upgraded machine, what do you get if you run vino-server on a command line?

[Glenn (g-mason)]

Same problem here. I'm running local network.

I was able to access 10.10 but unable to access 11.10. Firewall is off and unable to access 5900

[bigbodytad (bigbodytad)]

Running vino in the command line gives me this:

bigbodytad@bbt-mythbox:~$ /usr/lib/vino/vino-server

(vino-server:17593): EggSMClient-CRITICAL **: egg_sm_client_set_mode: assertion `global_client == NULL || global_client_mode == EGG_SM_CLIENT_MODE_DISABLED' failed
22/10/2011 04:32:28 PM Autoprobing TCP port in (all) network interface
22/10/2011 04:32:28 PM Listening IPv6://[::]:5900
22/10/2011 04:32:28 PM Listening IPv4://0.0.0.0:5900
22/10/2011 04:32:28 PM Autoprobing selected port 5900
22/10/2011 04:32:28 PM Advertising security type: 'TLS' (18)
22/10/2011 04:32:28 PM Re-binding socket to listen for VNC connections on TCP port 5900 in (all) interface
22/10/2011 04:32:28 PM Listening IPv6://[::]:5900
22/10/2011 04:32:28 PM Listening IPv4://0.0.0.0:5900
22/10/2011 04:32:28 PM Clearing securityTypes
22/10/2011 04:32:28 PM Advertising security type: 'TLS' (18)
22/10/2011 04:32:28 PM Clearing securityTypes
22/10/2011 04:32:28 PM Advertising security type: 'TLS' (18)
22/10/2011 04:32:28 PM Advertising authentication type: 'No Authentication' (1)
22/10/2011 04:32:28 PM Re-binding socket to listen for VNC connections on TCP port 5900 in (all) interface
22/10/2011 04:32:28 PM Listening IPv6://[::]:5900
22/10/2011 04:32:28 PM Listening IPv4://0.0.0.0:5900
22/10/2011 04:32:28 PM Clearing securityTypes
22/10/2011 04:32:28 PM Clearing authTypes
22/10/2011 04:32:28 PM Advertising security type: 'TLS' (18)
22/10/2011 04:32:28 PM Advertising authentication type: 'VNC Authentication' (2)
22/10/2011 04:32:28 PM Clearing securityTypes
22/10/2011 04:32:28 PM Clearing authTypes
22/10/2011 04:32:28 PM Advertising security type: 'TLS' (18)
22/10/2011 04:32:28 PM Advertising authentication type: 'VNC Authentication' (2)
22/10/2011 04:32:28 PM Advertising security type: 'VNC Authentication' (2)
Segmentation fault

[bigbodytad (bigbodytad)]

Running with sudo give me this, which makes me worry if it's even running. But according to the GUI, sharing is checked.

bigbodytad@bbt-mythbox:~$ sudo /usr/lib/vino/vino-server

** (vino-server:29514): WARNING **: The desktop sharing service is not enabled, so it should not be run.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ján Neščivera (yohny)]

I am experiencing this bug in Oneiric too, it looks like password entered in remote desktop preferences is ignored somehow (VNC clients in Windows and Ubuntu say 'Authentication failed'). As a workaround I'm able to set password using vino-passwd in terminal, then I'm able to access my computer remotely using that password

[bigbodytad (bigbodytad)]

The vino-passwd workaround didn't restore functionality for me, no change.

[Shawn Marie Richards (smrichar+launchpad)]

I was having this issue and found a workaround for my particular situation - I disabled the UPnP option and configured my router manually to forward the port, then disabled desktop sharing, then enabled it again (it did not work if I simply unchecked the box - the restart was required). I went back and tried several configurations after figuring this out, and it seemed to be the only variable that mattered for me. I had also tried a variety of solutions suggested in forums with no success.

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a backtrace following the instructions at http://wiki.ubuntu.com/DebuggingProgramCrash and upload the backtrace (as an attachment) to the bug report. This will greatly help us in tracking down your problem.

[Sebastien Bacher (seb128)]

do you have a manual network configuration? it seems similar to bug #883788

[bigbodytad (bigbodytad)]

I do not have a manual network configuration.

I am using the 32-bit version of 11.10.

Attached is the backtrace, ran using sudo

[bigbodytad (bigbodytad)]

Here is another backtrace, run without sudo

Hopefully this helps!

[Elmer Medez (emedez)]

I encountered this bug also in a freshly installed Ubuntu 11.10. When I try to access using tightvnc on Windows XP, authentication failed. The vino-password workaround mentioned in the previous comment worked for me. I tried to set the password using vino-passwd in terminal. Could it be that the desktop sharing GUI does not properly save the inputted password? I don't know.

[Feargal Reilly (feargal)]

I encountered this using an upgraded Ubuntu 11.10 with vino 3.2.0-0ubuntu1.

If I set the password through "Desktop Sharing" my clients could not authenticate, I tried with both TightVNC and AndroidVNC clients.
When I unchecked the option to require a password, both clients were then able to connect.

I found various threads from 2007/2008 where people had to hit backspace repeatedly to clear the password input box, I tried this but still whenever I set a password authentication failed.

Password length was 8 characters.

When I used vino-password to set the password my clients could then connect successfully.

As Elmer Medez suggested, it appeared the Desktop Sharing GUI has not been not saving the inputted password correctly.

Further testing suggests that, if a password has previously been set, the Desktop Sharing GUI does not overwrite it.

Steps to reproduce:
1) Use vino-passwd to set password to 'test1234'
2) Connect with client using 'test1234' as password - authentication succeeds.
3) Open "Desktop Sharing" GUI
4) Position cursor at end of password and use backspace four times to delete last four characters of password. Enter '5678' so that password should be 'test5678'.
5) Connect with client using 'test5678'. Authentication fails.
6) Connect with client using the old password of 'test1234'; Authenication succeeds.
7) Use vino-password to set password to 'test5678'
8) Connect with client using 'test1234'; Authentication fails.
9) Connect with client using 'test5678'; Authentication succeeds.

I know I've used the GUI to set a password for a new installation and that works fine, so I suspect the main condition for this bug is that a password has previously been set.

[Feargal Reilly (feargal)]

Note, I would view this as a security issue as a user could quite conceivably use the GUI to change the password to prevent a previously authorised user from reconnecting. The previsouly authorised user would still be able to connect using the old password issued to them.

[Sebastien Bacher (seb128)]

Thank you for the comments and details, does anyone get the issue on precise? Trying the steps from comment #16 it works fine here (the password is updated, client need to type the new password to connect)

[Hannes Kraus (pkxl2)]

Same for me, password changing in $ vino-passwd works, in $ vino-preferences it does not.
I'd like to add the following interesting feature: After changing the password in vino-passwd, the change is not reflected in the gnome configuration:

$ gconftool-2 -a /desktop/gnome/remote_access
 prompt_enabled = false
 authentication_methods = [vnc]
 vnc_password = bXVo <-- does not change
 enabled = true

[Sebastien Bacher (seb128)]

@Hannes: not sure what version of Ubuntu you use but vino stopped using gconf since oneiric in favor of gsettings