Ubuntu 14.04 (Alpha Release) - VNC not working

Bug #1290666 reported by nimsreny
120
This bug affects 25 people
Affects Status Importance Assigned to Milestone
vino (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

Hello Everyone,

I need your help to resolve the issue with VNC - Remore desktop connection. I upgraded my ubuntu from 12.04 LTS to 14.04 (Alpha) today. I was able to connect to Ubuntu desktop (12.04) from my IPAD using HippoRemote LIte or RealVNC before. But after upgradation to 14.04, this is not working all of a sudden. I tried many options to the best of my knowledge, including but not limited to, changing / restarting my router settings, reinstalling VNC server etc, changing default port 5900 to different and port forwading etc. But none of them worked.

It seems VINO is not listening to ipv4 connections, may be it conflicts with ipv6. Could any of you please help me how I can get through this.

nims@reny:~$ netstat -alpn | grep :5900
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 18615/vino-server
tcp6 0 0 :::5900 :::* LISTEN 18615/vino-server

Here are details about the version of ubuntu and the package for your perusal
nims@reny:~$ lsb_release -rd
Description: Ubuntu Trusty Tahr (development branch)
Release: 14.04
nims@reny:~$ apt-cache policy vino
vino:
  Installed: 3.8.1-0ubuntu1
  Candidate: 3.8.1-0ubuntu1
  Version table:
 *** 3.8.1-0ubuntu1 0
        500 http://us.archive.ubuntu.com/ubuntu/ trusty/main i386 Packages
        100 /var/lib/dpkg/status

Thanks!
nimsreny

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report. I can't confirm that. Do you get any error if you run "/usr/lib/vino/vino-server" by hand on a command line (stop the running instance if there is one first, then run the new one)

Changed in vino (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
nimsreny (nimsreny-linux) wrote :

Thanks Sebastien for responding.

I think this was similar bug reported in 2008. Bug : 196675.

https://bugs.launchpad.net/ubuntu/+source/vino/+bug/196675

I had done this before posting this bug. Per you suggestion I did the same again. I killed the instances of vino-server and then run it by hand on comand line as suggested. Here are the details. It seems it was not listening ipv4 connection for some reasons,

nims@reny:~$ netstat -alpn | grep :5900
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)

nims@reny:~$ netstat -alpn | grep :5900
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 9569/vino-server
tcp6 0 0 :::5900 :::* LISTEN 9569/vino-server

Any thoughts or workaround would be highly appreciated.

Thanks!

Revision history for this message
nimsreny (nimsreny-linux) wrote :

I was using my IPAD to access / control my desktop via HIppoRemote or RealVNC. This had been working before in 12.04 LTS, but stopped working after upgradation to 14.04. It is not even prompting to enter password and app is throwing out an error.

From HippoRemote APP: " Connection Error : Hippo Remove could not establish a connection with this computer. PLease make sue the computer is connected to the same network and is configured to accept connections from HIppo Remote. Also please make sure that your router and computer firewalls are not blocking access"

From VNC Viewer APP: "The authentication mechanism requested can not be provided by the computer"

As I detailed in my note, I tried all attempts to validate if everything is in place to the best of my knowledge. But none of them worked. This seems a bug in new release.

And this bug appears to be similar (or atlease close) to what we found in 2008,

https://bugs.launchpad.net/ubuntu/+source/vino/+bug/196675

Thanks!

Revision history for this message
Sebastien Bacher (seb128) wrote :

could you copy the output of the vino-server command?

Revision history for this message
nimsreny (nimsreny-linux) wrote :

Hello Sebatien,

I apologize as I didn't understand how I can do that. I'm new to Ubuntu and have only been used to this for 4 months. Please bear with me, but appreciate if you could let me know how I can capture the output of vino-server command

Thanks!

Revision history for this message
Sebastien Bacher (seb128) wrote :

you seem to know how to use a command line (you ran netstat commands), just open one and type "/usr/lib/vino/vino-server" and copy the output (like you did in previous comments) to the bug?

Revision history for this message
nimsreny (nimsreny-linux) wrote :

OKay. Thanks. I now understood what you had asked.

Here is what I see.

nims@reny:~$ /usr/lib/vino/vino-server

(vino-server:15158): EggSMClient-CRITICAL **: egg_sm_client_set_mode: assertion 'global_client == NULL || global_client_mode == EGG_SM_CLIENT_MODE_DISABLED' failed
** Message: The desktop sharing service is already running, exiting.
nims@reny:~$

KIndly let me know if that helps.

Revision history for this message
nimsreny (nimsreny-linux) wrote :

Also I stopped the running instances and then did this command again. And here is the output

nims@reny:~$ /usr/lib/vino/vino-server

(vino-server:15407): EggSMClient-CRITICAL **: egg_sm_client_set_mode: assertion 'global_client == NULL || global_client_mode == EGG_SM_CLIENT_MODE_DISABLED' failed
11/03/2014 02:07:00 PM Autoprobing TCP port in (all) network interface
11/03/2014 02:07:00 PM Listening IPv6://[::]:5900
11/03/2014 02:07:00 PM Listening IPv4://0.0.0.0:5900
11/03/2014 02:07:00 PM Autoprobing selected port 5900
11/03/2014 02:07:00 PM Advertising security type: 'TLS' (18)
11/03/2014 02:07:00 PM Re-binding socket to listen for VNC connections on TCP port 5900 in (all) interface
11/03/2014 02:07:00 PM Listening IPv6://[::]:5900
11/03/2014 02:07:00 PM Listening IPv4://0.0.0.0:5900
11/03/2014 02:07:00 PM Clearing securityTypes
11/03/2014 02:07:00 PM Advertising security type: 'TLS' (18)
11/03/2014 02:07:00 PM Clearing securityTypes
11/03/2014 02:07:00 PM Advertising security type: 'TLS' (18)
11/03/2014 02:07:00 PM Advertising authentication type: 'No Authentication' (1)
11/03/2014 02:07:00 PM Re-binding socket to listen for VNC connections on TCP port 5900 in (all) interface
11/03/2014 02:07:00 PM Listening IPv6://[::]:5900
11/03/2014 02:07:00 PM Listening IPv4://0.0.0.0:5900
11/03/2014 02:07:00 PM Clearing securityTypes
11/03/2014 02:07:00 PM Clearing authTypes
11/03/2014 02:07:00 PM Advertising security type: 'TLS' (18)
11/03/2014 02:07:00 PM Advertising authentication type: 'VNC Authentication' (2)

Revision history for this message
nimsreny (nimsreny-linux) wrote :

11/03/2014 02:12:06 PM [IPv4] Got connection from client Nimmys-iPad.PK5001Z
11/03/2014 02:12:06 PM other clients:
11/03/2014 02:12:06 PM Client Protocol Version 3.7
11/03/2014 02:12:06 PM Advertising security type 18
11/03/2014 02:12:06 PM Client returned security type 0
11/03/2014 02:12:06 PM rfbAuthProcessSecurityTypeMessage: client returned unadvertised security type 0
11/03/2014 02:12:06 PM Client Nimmys-iPad.PK5001Z gone
11/03/2014 02:12:06 PM Statistics:
11/03/2014 02:12:06 PM framebuffer updates 0, rectangles 0, bytes 0
11/03/2014 02:12:12 PM [IPv4] Got connection from client Nimmys-iPad.PK5001Z
11/03/2014 02:12:12 PM other clients:
11/03/2014 02:12:12 PM Client Protocol Version 3.7
11/03/2014 02:12:12 PM Advertising security type 18
11/03/2014 02:12:12 PM Client returned security type 0
11/03/2014 02:12:12 PM rfbAuthProcessSecurityTypeMessage: client returned unadvertised security type 0
11/03/2014 02:12:12 PM Client Nimmys-iPad.PK5001Z gone
11/03/2014 02:12:12 PM Statistics:
11/03/2014 02:12:12 PM framebuffer updates 0, rectangles 0, bytes 0

Revision history for this message
Sebastien Bacher (seb128) wrote :

seems like it's getting the connection but not liking the client response to the security check? The issue The issue could be one with the client or an upstream one, in which case it would be nice if somebody could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME.

Changed in vino (Ubuntu):
status: Incomplete → New
Revision history for this message
nimsreny (nimsreny-linux) wrote :

Thanks Sebastien. I filed this bug to Vino Developers / Maintainers.

Here is https://bugzilla.gnome.org/show_bug.cgi?id=726137

Thanks for your support with this.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in vino (Ubuntu):
status: New → Confirmed
Revision history for this message
James Landrum (james-landrum1) wrote :

I too use HippoRemote and am experiencing the same issues! All I did was restart my router, my iPhone, and my PC as per the the troubleshooting instructions from HippoRemote, and still no connection. It does detect my PC, but it will not connect.

Revision history for this message
Jon Mirow (gnu-mirow) wrote :

confirmed Using Jump Dektop on iOS 7.1

Revision history for this message
James Landrum (james-landrum1) wrote :

Please fix this. It worked just fine in 13.10 and now it does not. My laptop has a faulty touchpad and sometimes HippoRemote is my only choice. The issue is NOT with HippoRemote, it is with Ubuntu 14.04. Please start working on this!

Revision history for this message
XabiX (xdealmeida) wrote :

My stopped working also after the upgrade from 13.10 to 14.04. I don't get exactly to the same pt as you guys. I tried with two uptodate clients from RealVNC and tightVNC.

xabix@HTPC:~$ sudo /usr/lib/vino/vino-server start |

(vino-server:20098): EggSMClient-CRITICAL **: egg_sm_client_set_mode: assertion 'global_client == NULL || global_cl
ient_mode == EGG_SM_CLIENT_MODE_DISABLED' failed
30/03/2014 18:20:44 Autoprobing TCP port in (all) network interface
30/03/2014 18:20:44 Listening IPv6://[::]:5900
30/03/2014 18:20:44 Listening IPv4://0.0.0.0:5900
30/03/2014 18:20:44 Autoprobing selected port 5900
30/03/2014 18:20:44 Advertising security type: 'TLS' (18)
30/03/2014 18:20:44 Re-binding socket to listen for VNC connections on TCP port 5900 in (all) interface
30/03/2014 18:20:44 Listening IPv6://[::]:5900
30/03/2014 18:20:44 Listening IPv4://0.0.0.0:5900
30/03/2014 18:20:44 Clearing securityTypes
30/03/2014 18:20:44 Advertising security type: 'TLS' (18)
30/03/2014 18:20:44 Clearing securityTypes
30/03/2014 18:20:44 Advertising security type: 'TLS' (18)
30/03/2014 18:20:44 Advertising authentication type: 'No Authentication' (1)
30/03/2014 18:20:44 Re-binding socket to listen for VNC connections on TCP port 5900 in (all) interface
30/03/2014 18:20:44 Listening IPv6://[::]:5900
30/03/2014 18:20:44 Listening IPv4://0.0.0.0:5900

RealVNC client
30/03/2014 18:21:02 [IPv4] Got connection from client lenovo-wifi.home
30/03/2014 18:21:02 other clients:
30/03/2014 18:21:02 Client Protocol Version 3.7
30/03/2014 18:21:02 Advertising security type 18
30/03/2014 18:21:02 Client lenovo-wifi.home gone
30/03/2014 18:21:02 Statistics:
30/03/2014 18:21:02 framebuffer updates 0, rectangles 0, bytes 0

TightVNC client
30/03/2014 18:23:50 [IPv4] Got connection from client lenovo-wifi.home
30/03/2014 18:23:50 other clients:
30/03/2014 18:23:50 Client Protocol Version 3.7
30/03/2014 18:23:50 Advertising security type 18
30/03/2014 18:23:53 Client lenovo-wifi.home gone
30/03/2014 18:23:53 Statistics:
30/03/2014 18:23:53 framebuffer updates 0, rectangles 0, bytes 0

Revision history for this message
Demetris Lambrou (demetrislambrou123) wrote :

I had the similar problem with Fedora 20, gnome 3.12 and I was able to find a workaround and was able to work hipporemote. I think that the same workaround will work with Ubuntu 14.04 but not sure you could try.

I used dconf-editor and under org.gnome.desktop.remote-access you will find a key require-encryption that it is turn on as a default. I turned that on and it was working for me. Under ubuntu 14.04 maybe is gnome.desktop.remote-access but I am not sure. Just search require-encryption in dconf and disable it if is turned on and it might help.

Revision history for this message
livio (livio-devito) wrote :

i have the same problem: HippoRemote worked on ubuntu 13.10, and now nothing! Same answers of terminal, and same bug. Help!

Revision history for this message
livio (livio-devito) wrote :

exactly I use Xubuntu, not Ubuntu, but I think it's the same problem

Revision history for this message
Art Bouvier (paparoux) wrote :

THANK YOU ALL SO MUCH!
dconf-editor > disable REQUIRE ENCRYPTION worked!

Revision history for this message
XabiX (xdealmeida) wrote :

Great it works merci!!!!!!!!!!!
still this needs to be fixed or default value should be disable till we get a patch

Revision history for this message
Jaime Carpenter (j.carpenter) wrote :

I had the same problem using VNC from my Chromebook and after updating to Ubuntu 14.04 LTS. I used the suggestion of the dconf-editor -> org.gnome.desktop.remote-access then "require-encryption = NO"

Revision history for this message
Kyle Jackson (kylejackson) wrote :

Having the same issue but not quite sure how to use dconf to fix it (new Ubuntu user), can anyone help?

Revision history for this message
Skorpion (ss-ssfera) wrote :

Kyle Jackson (kylejackson)
-1.
sudo apt-get install dconf-editor

and start it...
-2.
org > gnome > desktop > applications > remote-access
-3.
disable "REQUIRE-ENCRYPTION"

Revision history for this message
*stargazer* (jigsaw310) wrote :

changing values in dconf-editor doesn't help. I still cannot connect and after restart the require-encryption is 'true'.

Revision history for this message
Nilfred (nilfred) wrote :

sudo apt-get -y install dconf-tools
dconf read /org/gnome/desktop/remote-access/require-encryption
true
dconf write /org/gnome/desktop/remote-access/require-encryption false
/usr/lib/vino/vino-server --sm-disable start

** (vino-server:18244): WARNING **: The desktop sharing service is not enabled, so it should not be run.
ps x | grep vino
18248 pts/0 S+ 0:00 grep --color=auto vino

So, how do I enable "The desktop sharing service"?

Revision history for this message
Nilfred (nilfred) wrote :

gsettings set org.gnome.Vino enabled true
/usr/lib/vino/vino-server --sm-disable
...
20/04/2014 19:07:55 [IPv6] Got connection from client localhost
20/04/2014 19:07:55 other clients:
20/04/2014 19:07:55 Client Protocol Version 3.7
20/04/2014 19:07:55 Advertising security type 18
20/04/2014 19:07:55 Advertising security type 1
20/04/2014 19:07:56 Client returned security type 18
20/04/2014 19:07:56 TLS Handshake failed: A TLS packet with unexpected length was received.
20/04/2014 19:07:56 Client localhost gone
...
Using bVNC Free for Android that used to work before downgrading from Ubuntu 12.04 to 14.04

Revision history for this message
Nilfred (nilfred) wrote :

Error as reported from bVNC:
Connection failed.
Connection to VNC server failed with reason: Illegal cipher suite strings.

Revision history for this message
nitrogen dream (nitrogendream) wrote :

Guys,

The problem is simple.
If you take a Wireshark trace you immediately see the issue.
You will have to filter on VNC.
The supported security type which is given for 14.04 is "type 18, TLS".
For 13.10 we see two types, "type 18, TLS" and "type 2, VNC".

The "type 2, VNC" is used by your VNC viewer.
So adding type 2 in the proposed supported security types will solve this bug.

Revision history for this message
lelissam (lelissam) wrote :

$ gsettings set org.gnome.Vino require-encryption false

Revision history for this message
Deogratias James (deouisso) wrote :

thanks demetris, it worked

Revision history for this message
ken hal (kendonkottz) wrote :

Thank you the info led me to finding a solution as the encryption selection was unchecked already in dconf org>gnome>desktop>remote access but selecting the - use alternative port and checking it on will most likely solve your problem as hippo uses 5900 as the default port

Revision history for this message
Jim (linaro-jimdonelson) wrote :

That fixed for me too dconf org>gnome>desktop>remote access.
Wow, 14.04 was brutal for me - I spent all day get ssh,samba and vnc to work.
Mostly because I thought I had these things down, but stuff got changed.
This one had me pounding the keyboard :-)...

Revision history for this message
BillT (bill-wz6b3) wrote :

dconf-editor and changing the org.gnome.desktop.remote access as indicated worked for me - apparently the default setting is whats screwing it up - I wonder what would happen if I tried using some type of encryption? But not enough to change anything!

Thank you so much for posting this fix.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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