Bug 1275750

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.

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.

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).

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.

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!!

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

*** Bug 1281600 has been marked as a duplicate of this bug. ***

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
===========================

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.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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.

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.