Bug 1275750 - Vinagre Fails to Connect to VNC Host
Vinagre Fails to Connect to VNC Host
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: vinagre (Show other bugs)
23
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Felipe Borges
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-27 11:56 EDT by rmarshall
Modified: 2016-12-20 10:11 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 10:11:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description rmarshall 2015-10-27 11:56:35 EDT
Description of problem:
Remote Desktop VNC (Vinagre) fails to connect to an F23 installation.

Version-Release number of selected component (if applicable):
3.18.1

How reproducible:
Use virt-install to create an F23 guest with KVM.


Steps to Reproduce:
1. Install F23 Workstation to Bare Metal Machine
2. Configure bridge on host's external ethernet connection and add to /etc/qemu/bridge.conf
3. systemctl restart libvirtd
4. Run virt-install (see additional info for exact CLI I used)
5. Attempt to connect to F23 guest from F23 host

Actual results:
VNC automatically disconnects.

Expected results:
Connected VNC session.

Additional info:
virt-install --name DEV_MACHINE --memory 2048 --disk path=/srv/vmachines/machines/dev_machine.qcow2,size=10,format=qcow2,bus=virtio,cache=none --location <path_to_f23_beta_os_directory> --extra-args='console=ttyS0 serial vnc sshd' --graphics none --network bridge=br0

Also note - I can connect to the F23 installer using Vinagre/Remote Desktop from an F22 desktop.

I have also tried dropping all firewalls on the F23 host on the off chance it was a firewall issue - no change.

Running Vinagre with vinagre --gtk-vnc-debug - output below

(vinagre:5726): gtk-vnc-DEBUG: vncconnection.c Init VncConnection=0x56102e385920
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Using X11 backend
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c XKB keyboard map name 'evdev_aliases(qwerty)'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Server vendor is 'Fedora Project'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'Generic Event Extension'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'SHAPE'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'MIT-SHM'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XInputExtension'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XTEST'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'BIG-REQUESTS'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'SYNC'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XKEYBOARD'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XC-MISC'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XFIXES'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'RENDER'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'RANDR'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XINERAMA'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'Composite'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'DAMAGE'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'MIT-SCREEN-SAVER'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'DOUBLE-BUFFER'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'RECORD'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'DPMS'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'Present'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'X-Resource'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XVideo'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XFree86-VidModeExtension'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XFree86-DGA'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'DRI2'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'GLX'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'SGI-GLX'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Wayland display '<none>'
(vinagre:5726): gtk-vnc-DEBUG: vncdisplaykeymap.c Using evdev keycode mapping
(vinagre:5726): gtk-vnc-DEBUG: vncdisplay.c Grab sequence is now Control_L+Alt_L
(vinagre:5726): gtk-vnc-DEBUG: vncconnection.c Open host=10.19.52.232:1 port=5900
(vinagre:5726): gtk-vnc-DEBUG: vncconnection.c Open coroutine starting
(vinagre:5726): gtk-vnc-DEBUG: vncconnection.c Started background coroutine
(vinagre:5726): gtk-vnc-DEBUG: vncconnection.c Resolving host 10.19.52.232:1 5900
(vinagre:5726): gtk-vnc-DEBUG: vncconnection.c Doing final VNC cleanup
(vinagre:5726): gtk-vnc-DEBUG: vncconnection.c Close VncConnection=0x56102e385920
(vinagre:5726): gtk-vnc-DEBUG: vncconnection.c Emit main context 15
(vinagre:5726): gtk-vnc-DEBUG: vncdisplay.c Disconnected from VNC server
(vinagre:5726): gtk-vnc-DEBUG: vncdisplay.c Display destroy, requesting that VNC connection close
(vinagre:5726): gtk-vnc-DEBUG: vncdisplay.c Display destroy, requesting that VNC connection close
(vinagre:5726): gtk-vnc-DEBUG: vncdisplay.c Releasing VNC widget
(vinagre:5726): gtk-vnc-DEBUG: vncconnection.c Delayed unref VncConnection=0x56102e385920
(vinagre:5726): gtk-vnc-DEBUG: vncconnection.c Finalize VncConnection=0x56102e385920
Comment 1 rmarshall 2015-10-27 14:17:50 EDT
I can also confirm that the same error (immediate disconnect) happens when using Vinagre 3.18.1 on Fedora 23 Beta Workstation on x86 to connect to a guest installation of Fedora 22 on an IBM POWER 8 server.
Comment 2 Adam Williamson 2015-10-27 14:34:43 EDT
So yeah, I can reproduce this. To be clear, there seems to be a problem *only* with Vinagre running on F23 connecting to the installer's VNC server (which is Xvnc). These combinations work:

1. F22 Vinagre connecting to installer
2. F22 or F23 Vinagre connecting to GNOME VNC session (under 'Sharing', enable 'Screen Sharing', whatever server that uses)

The only combination that doesn't work is:

F23 Vinagre connecting to installer

for all cases it doesn't seem to matter whether the server is F22 or F23 - F23 Vinagre can't connect to an F22 or F23 installation, F22 Vinagre can connect to an F22 or F23 installation.
Comment 3 Adam Williamson 2015-10-27 14:35:54 EDT
Another combination that works: TigerVNC viewer on F23 connecting to the installer. So F23 Vinagre is clearly not entirely broken (as it can connect to the GNOME VNC server, whatever that is), but it has some kind of bug specifically with connecting to the installer VNC server (or just Xvnc in general, possibly).
Comment 4 Brian Lane 2015-10-27 14:57:52 EDT
Also note that I can use my gvncviewer script to connect (https://bcl.fedorapeople.org/scripts/gvncviewer.py) on the same system (F23 Workstation running the VM locally) that vinagre fails on.
Comment 5 Rubén Dután 2015-11-13 08:40:26 EST
I have similar problem after to upgrade to F23. 
I can not connect to Xvnc Server with F23 
I have the same version in the client.
It's work with tiger viewer with problems. the screen not show correctly!!
Comment 6 Ting-Wei Lan 2015-11-17 07:53:41 EST
Upgrading to 3.18.2 fixes the problem for me.

https://bugzilla.redhat.com/show_bug.cgi?id=1281600
https://bugzilla.gnome.org/show_bug.cgi?id=710173
Comment 7 Adam Williamson 2015-11-17 14:35:49 EST
*** Bug 1281600 has been marked as a duplicate of this bug. ***
Comment 8 Dennis W. Tokarski 2016-01-26 21:59:25 EST
This still doesn't work. F23 vinagre can't connect to
F23 vino-server.

This is with a host system and a VM, both up to date
as of 0030 UTC 26 January.

Both use mate. If vino-server has deliberately been
modified to work only with gnome, then obviously there
are bigger problems.

Anyone have any ideas about what's going wrong here?

Using:
vino-3.18.1-1.fc23.x86_64
vinagre-3.18.2-1.fc23.x86_64


Starting vino-server on the VM in a mate-terminal:

[PolTec@raid-lvm-scratch Desktop]$ /usr/libexec/vino-server --tube
** Message: Started in tube mode; reject network connections
26/01/2016 09:39:22 PM Autoprobing TCP port in (all) network interface
26/01/2016 09:39:22 PM Listening IPv6://[::]:5900
26/01/2016 09:39:22 PM Listening IPv4://0.0.0.0:5900
26/01/2016 09:39:22 PM Autoprobing selected port 5900
26/01/2016 09:39:22 PM Advertising security type: 'TLS' (18)
26/01/2016 09:39:22 PM Re-binding socket to listen for VNC connections on TCP port 5900 in (all) interface
26/01/2016 09:39:22 PM Listening IPv6://[::]:5900
26/01/2016 09:39:22 PM Listening IPv4://0.0.0.0:5900
26/01/2016 09:39:22 PM Clearing securityTypes
26/01/2016 09:39:22 PM Advertising security type: 'TLS' (18)
26/01/2016 09:39:22 PM Clearing securityTypes
26/01/2016 09:39:22 PM Advertising security type: 'TLS' (18)
26/01/2016 09:39:22 PM Advertising authentication type: 'No Authentication' (1)
26/01/2016 09:39:22 PM Re-binding socket to listen for VNC connections on TCP port 5900 in (all) interface
26/01/2016 09:39:22 PM Listening IPv6://[::]:5900
26/01/2016 09:39:22 PM Listening IPv4://0.0.0.0:5900
26/01/2016 09:39:22 PM Listening for VNC connections on TCP port 5900 in (all) network interface
26/01/2016 09:39:22 PM Listening IPv6://[::]:5900
26/01/2016 09:39:22 PM Listening IPv4://0.0.0.0:5900
26/01/2016 09:39:22 PM Listening for VNC connections on TCP port 5902 in (all) network interface
26/01/2016 09:39:22 PM Listening IPv6://[::]:5902
26/01/2016 09:39:22 PM Listening IPv4://0.0.0.0:5902
26/01/2016 09:39:22 PM Clearing securityTypes
26/01/2016 09:39:22 PM Clearing authTypes
26/01/2016 09:39:22 PM Advertising security type: 'TLS' (18)
26/01/2016 09:39:22 PM Advertising authentication type: 'No Authentication' (1)
26/01/2016 09:39:22 PM Advertising security type: 'No Authentication' (1)

26/01/2016 09:40:48 PM [IPv4] Got connection from client gateway
26/01/2016 09:40:48 PM   other clients:
26/01/2016 09:40:48 PM Client gateway gone
26/01/2016 09:40:48 PM Statistics:
26/01/2016 09:40:48 PM   framebuffer updates 0, rectangles 0, bytes 0

Starting vinagre on the host system in a mate-temrinal:
[PolTec@herakles Desktop]$ vinagre --gtk-vnc-debug 2>&1 | tee vinagre.log

vinagre.log:
==========================
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Init VncConnection=0x563baf6ddb90
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Using X11 backend
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c XKB keyboard map name 'evdev_aliases(qwerty)'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Server vendor is 'The X.Org Foundation'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'VNC-EXTENSION'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'Generic Event Extension'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'SHAPE'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'MIT-SHM'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XInputExtension'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XTEST'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'BIG-REQUESTS'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'SYNC'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XKEYBOARD'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XC-MISC'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XFIXES'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'RENDER'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'RANDR'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XINERAMA'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'Composite'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'DAMAGE'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'MIT-SCREEN-SAVER'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'DOUBLE-BUFFER'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'RECORD'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'DPMS'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'Present'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'X-Resource'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'XVideo'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'GLX'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Found extension 'SGI-GLX'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Wayland display '<none>'
(vinagre:2970): gtk-vnc-DEBUG: vncdisplaykeymap.c Using evdev keycode mapping
(vinagre:2970): gtk-vnc-DEBUG: vncdisplay.c Grab sequence is now Control_L+Alt_L
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Open host=192.168.122.248 port=5902
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Open coroutine starting
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Started background coroutine
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Resolving host 192.168.122.248 5902
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Trying one socket
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Socket pending
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Finally connected
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Emit main context 13
(vinagre:2970): gtk-vnc-DEBUG: vncdisplay.c Connected to VNC server
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Protocol initialization
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Read error Resource temporarily unavailable
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Server version: 3.7
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Using version: 3.7
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Closing the connection: vnc_connection_read() - ret=0
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Auth failed
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Doing final VNC cleanup
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Close VncConnection=0x563baf6ddb90
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Emit main context 15
(vinagre:2970): gtk-vnc-DEBUG: vncdisplay.c Disconnected from VNC server
(vinagre:2970): gtk-vnc-DEBUG: vncdisplay.c Display destroy, requesting that VNC connection close
(vinagre:2970): gtk-vnc-DEBUG: vncdisplay.c Display destroy, requesting that VNC connection close
(vinagre:2970): gtk-vnc-DEBUG: vncdisplay.c Releasing VNC widget
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Delayed unref VncConnection=0x563baf6ddb90
(vinagre:2970): gtk-vnc-DEBUG: vncconnection.c Finalize VncConnection=0x563baf6ddb90
===========================
Comment 9 Dennis W. Tokarski 2016-03-13 22:02:33 EDT
Hi again,

The observations in my previous column still hold. I was using the --tube option as described in the --help text and several examples found on the web. At some time past, someone thought it worked.

If --tube is omitted, the desktop can be shared as expected. Go figure.

Next problem up is that when vino-server is launched in mate as a startup program, it won't really start. There are complaints in the log about not being able to find the enable key.

That key used to be in /usr/share/glib-2.0/schemas/org.gnome.Vino.gschema.xml from the vino package. It is now missing. I suspect it was removed and relocated in the gnome desktop settings program package (gnome-control-center?).

As an experiment I placed the following stanza in the vino schema file:

    <key name='enabled' type='b'>
      <summary>Enable desktop sharing</summary>
      <description>
        If true, remote users may access the desktop.
      </description>
      <default>false</default>
    </key>

After using deconf-editor to set the enable key and other options as needed, and after adding a Desktop Sharing menu item (and enabling it) in the mate startup applications list, and logging back out and in again, I found vino-server listening on its designated port. The following vinagr->vino connection use cases now work:

  Client                           Connects To
vinagre-3.18.2-1.fc23.x86_64       vino-3.18.1-1.fc23.x86_64 on the VM running
on host computer running F23       F23

vinagre-3.10.2-1.fc20.x86_64 on    vino-3.18.1-1.fc23.x86_64 on the F23 VM
another host running F20

vinagre-3.10.2-1.fc20.x86_64 on    vino-3.18.1-1.fc23.x86_64 on the F23 host
the F20 host

This should have worked out of the box and instead comes at the cost of hours of research and experiment. 

I would ask that the vino enable flag be put back in the vino schema file. It is, after all, an aspect of vino-server's configuration and not any particular configuration program, e.g., gnome-control-center.

And closely related to that, it would be convenient if the vino package put the desktop file back in /etc/xdg rather (or in addition to) /usr/share/applications/vino-server.

Really, this stuff should work out of the box. It used to, after all.

Thanks.
Comment 10 Fedora Admin XMLRPC Client 2016-09-15 10:55:10 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 11 Fedora End Of Life 2016-11-24 07:56:21 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 12 Fedora End Of Life 2016-12-20 10:11:06 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.