RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 921330 - Remote-viewer shows no error if connect to a spice port through vnc protocol
Summary: Remote-viewer shows no error if connect to a spice port through vnc protocol
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gtk-vnc
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Daniel Berrangé
QA Contact: SPICE QE bug list
URL:
Whiteboard:
Depends On: 1416692 1416783
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-14 02:49 UTC by Geyang Kong
Modified: 2017-08-01 19:55 UTC (History)
13 users (show)

Fixed In Version: gtk-vnc-0.7.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 882110
: 1416692 1448151 (view as bug list)
Environment:
Last Closed: 2017-08-01 19:55:38 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2258 0 normal SHIPPED_LIVE Moderate: gtk-vnc security, bug fix, and enhancement update 2017-08-01 18:21:01 UTC

Description Geyang Kong 2013-03-14 02:49:28 UTC
+++ This bug was initially created as a clone of Bug #882110 +++

Description of problem:
Remote-viewer shows no error if connect to a spice port through vnc protocol

Version-Release number of selected component (if applicable):
virt-viewer-0.5.2-16.el6.x86_64
libvirt-0.10.2-10.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Prepare a spice guest,set it port as 5900.
# virsh dumpxml test
    <graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>


2. Use remote-viewer vnc instead spice to connect the guest,the window just pop out without error showed.
# remote-viewer vnc://localhost:5900 --debug
connect : Connection refused
** (remote-viewer:14182): DEBUG: Insert window 0 0x13f5890
** (remote-viewer:14182): DEBUG: fullscreen display 0: 0
** (remote-viewer:14182): DEBUG: fullscreen display 0: 0
** (remote-viewer:14182): DEBUG: Opening display to vnc://localhost:5900
** (remote-viewer:14182): DEBUG: Guest vnc://localhost:5900 has a vnc display
** (remote-viewer:14182): DEBUG: After open connection callback fd=-1
** (remote-viewer:14182): DEBUG: Opening connection to display at vnc://localhost:5900
** (remote-viewer:14182): DEBUG: notebook show status 0x13f60a0
** (remote-viewer:14182): DEBUG: notebook show status 0x13f60a0
** (remote-viewer:14182): DEBUG: notebook show display 0x13f60a0
** (remote-viewer:14182): DEBUG: Display size request 100x100 (desktop 100x100)
** (remote-viewer:14182): DEBUG: Allocated 400x375
** (remote-viewer:14182): DEBUG: Child allocate 375x375
** (remote-viewer:14182): DEBUG: Display size request 50x50 (desktop 100x100)
** (remote-viewer:14182): DEBUG: Allocated 400x375
** (remote-viewer:14182): DEBUG: Child allocate 375x375
** (remote-viewer:14182): DEBUG: Window closed
** (remote-viewer:14182): DEBUG: close vnc=0x13de760
** (remote-viewer:14182): DEBUG: Disconnected
** (remote-viewer:14182): DEBUG: close vnc=0x138b880
** (remote-viewer:14182): DEBUG: notebook show status 0x13f60a0
** (remote-viewer:14182): DEBUG: Guest vnc://localhost:5900 display has disconnected, shutting down
** (remote-viewer:14182): DEBUG: Disposing window 0x13f5890

** (remote-viewer:14182): DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0

3.If use remote-viewer vnc to connect a guest with port which doesn't exist even for spice,there is error:
eg:
# remote-viewer vnc://localhost:5909 
Window pop out,and error shows as:Unable to connect to the graphic server vnc://localhost:5909


Actual results:
As step2 shows.

Expected results:
There is error messages shows:Unable to connect to the graphic server vnc://localhost:5900

Additional info: 
1.Remote-viewer shows error if connect to a vnc port through spice protocol,error showed as:Unable to connect to the graphic server spice://$ip:$port

This bus still appeared on RHEL7-20130306.0, so clone it to rhel7

Comment 2 hyao@redhat.com 2013-05-16 09:32:00 UTC
The bug reproduce with the following packages
libvirt-1.0.5-2.el7.x86_64
virt-viewer-0.5.6-1.el7.x86_64

Comment 4 RHEL Program Management 2014-03-24 05:53:05 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 6 Fabiano Fidêncio 2014-09-16 14:25:26 UTC
Reassigning to gtk-vnc, according to: https://bugzilla.redhat.com/show_bug.cgi?id=882110#c3

Comment 8 Daniel Berrangé 2017-01-26 09:30:43 UTC
Figured out a way to fix this in combination with a SPICE server patch to more proactively detect & drop bogus clients.

Solution is described in https://lists.freedesktop.org/archives/spice-devel/2017-January/035201.html

Comment 9 Daniel Berrangé 2017-01-26 09:34:26 UTC
commit 7f4f2fe8da72ed9fef5dd4319e19feb2b4f3d62e
Author: Daniel P. Berrange <berrange>
Date:   Thu Jan 26 09:31:40 2017 +0000

    Add workaround to avoid hangs when connecting to SPICE
    
    When used with QEMU at least, both SPICE and VNC live in the same port
    range (5900+). It is thus not entirely uncommon for a user to mistakenly
    connect to a SPICE server with a VNC client, or vica-verca.
    
    When connecting to VNC server with a SPICE client, you quickly get an
    error. This is because the VNC server sends its short greeting and then
    sees the RedLinkMess from the SPICE client, realizes its garbage and
    drops the connection.
    
    When connecting to a SPICE server with a VNC client though, you get an
    indefinite hang. The VNC client is waiting for the VNC greeting, which
    the SPICE server will never send. The SPICE server is waiting for the
    RedLinkMess which the VNC client will never send.
    
    In VNC the protocol starts with the follow data sent:
    
     Server: "RFB 003.008\n"
     Client: "RFB 003.008\n"
    
    This can be tweaked so the client proactively sends the first four
    bytes
    
     Client: "RFB "
     Server: "RFB 003.008\n"
     Client: "003.008\n"
    
    From the VNC server POV, it'll still be receiving the same 12 bytes from
    the client - it just happens that 4 of them might arrive a tiny bit
    earlier than the other 8 of them. IOW nothing should break in the VNC
    server from this change.
    
    The SPICE server, waiting for its RedLinkMess message will see these
    four bytes "RFB " and interpret them as the SPICE magic number. This
    will be invalid and so the SPICE server will drop the connection.
    This avoids the VNC client hanging forever when connecting to a SPICE
    server by mistake.
    
    Signed-off-by: Daniel P. Berrange <berrange>

Comment 10 Daniel Berrangé 2017-01-26 09:36:54 UTC
This requires a corresponding fix in the SPICE server in order to work https://bugzilla.redhat.com/show_bug.cgi?id=1416692

Comment 15 Bill Sanford 2017-04-24 18:09:33 UTC
Tested with: 

virt-viewer-5.0-2
libvirt-3.2.0-3

There is still no error message and the VNC display has "Waiting for display 1..." 

The debug output:

[root@dhcp-10-19-63-104 images]# remote-viewer vnc://localhost:5900 --debug
(remote-viewer:29067): virt-viewer-DEBUG: Opening display to vnc://localhost:5900
(remote-viewer:29067): virt-viewer-DEBUG: Guest (null) has a vnc display
(remote-viewer:29067): virt-viewer-DEBUG: After open connection callback fd=-1
(remote-viewer:29067): virt-viewer-DEBUG: Opening connection to display at vnc://localhost:5900
(remote-viewer:29067): virt-viewer-DEBUG: notebook show status 0x5626612fa230
(remote-viewer:29067): virt-viewer-DEBUG: notebook show status 0x5626612fa230
(remote-viewer:29067): virt-viewer-DEBUG: Insert display 0 0x5626610e0660
(remote-viewer:29067): virt-viewer-DEBUG: notebook show status 0x5626612fa230
(remote-viewer:29067): virt-viewer-DEBUG: Allocated 1024x740
(remote-viewer:29067): virt-viewer-DEBUG: Child allocate 1024x640

(remote-viewer:29067): Gtk-WARNING **: Allocating size to VncDisplay 0x5626613ac230 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

Comment 16 Christophe Fergeau 2017-04-25 08:41:40 UTC
spice-server is missing a required patch, see rhbz#1416692

Comment 17 Christophe Fergeau 2017-04-25 09:39:15 UTC
(In reply to Bill Sanford from comment #15)
> Tested with: 
> 
> virt-viewer-5.0-2
> libvirt-3.2.0-3
> 
> There is still no error message and the VNC display has "Waiting for display
> 1..." 

Hopefully this will work as expected with spice-0.12.8-2.el7

Comment 18 Bill Sanford 2017-04-25 10:48:45 UTC
Yeah, this version is spice-server-0.12.8-1.el7

Comment 19 Bill Sanford 2017-04-25 11:00:08 UTC
I updated the machine with spice-server-0.12.8-2.el7 and I get the same error as the previous version.

Comment 20 Bill Sanford 2017-04-25 12:09:13 UTC
Installed RHEL-7.4-20170421.1 and updated spice server to spice-server-0.12.8-2.el7 and completely rebooted VM and machine.

Comment 21 Bill Sanford 2017-05-04 13:46:48 UTC
I installed RHEL-7.4-20170426.4 and the command remote-viewer "vnc://localhost:5900 --debug" shows: 

[root@dhcp-10-19-63-104 test]# remote-viewer vnc://127.0.0.1:5900 --debug
(remote-viewer:14526): virt-viewer-DEBUG: Opening display to vnc://127.0.0.1:5900
(remote-viewer:14526): virt-viewer-DEBUG: Guest (null) has a vnc display
(remote-viewer:14526): virt-viewer-DEBUG: After open connection callback fd=-1
(remote-viewer:14526): virt-viewer-DEBUG: Opening connection to display at vnc://127.0.0.1:5900
(remote-viewer:14526): virt-viewer-DEBUG: notebook show status 0x558a27354230
(remote-viewer:14526): virt-viewer-DEBUG: notebook show status 0x558a27354230
(remote-viewer:14526): virt-viewer-DEBUG: Insert display 0 0x558a27136660
(remote-viewer:14526): virt-viewer-DEBUG: notebook show status 0x558a27354230
(remote-viewer:14526): virt-viewer-DEBUG: Allocated 1024x740
(remote-viewer:14526): virt-viewer-DEBUG: Child allocate 1024x640

(remote-viewer:14526): Gtk-WARNING **: Allocating size to VncDisplay 0x558a27406230 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
(remote-viewer:14526): virt-viewer-DEBUG: Not removing main window 0 0x558a27119320
(remote-viewer:14526): virt-viewer-DEBUG: Disconnected
(remote-viewer:14526): virt-viewer-DEBUG: close vnc=0x558a27406230
(remote-viewer:14526): virt-viewer-DEBUG: notebook show status 0x558a27354230
(remote-viewer:14526): virt-viewer-DEBUG: Guest (null) display has disconnected, shutting down
[root@dhcp-10-19-63-104 test]# 

The remote-viewer opens and then closes with no error of not being able to connect to server. The "spice://localhost:5900 --debug" command shows the error message while trying to connect to a VNC server.

Comment 22 Christophe Fergeau 2017-05-04 13:54:41 UTC
I think for now it's expected that no error message is shown.

Comment 23 Radek Duda 2017-05-04 15:13:31 UTC
(In reply to Christophe Fergeau from comment #22)
> I think for now it's expected that no error message is shown.

Can you explain this? 

In https://bugzilla.redhat.com/show_bug.cgi?id=921330#c0 is clearly stated Expected results:
There is error messages shows:Unable to connect to the graphic server vnc://localhost:5900

Comment 24 Christophe Fergeau 2017-05-04 15:27:51 UTC
(In reply to Radek Duda from comment #23)
> (In reply to Christophe Fergeau from comment #22)
> > I think for now it's expected that no error message is shown.
> 
> Can you explain this? 
> 
> In https://bugzilla.redhat.com/show_bug.cgi?id=921330#c0 is clearly stated
> Expected results:
> There is error messages shows:Unable to connect to the graphic server
> vnc://localhost:5900

I know what the bug description is saying, but I think that what is currently implemented is that remote-viewer no longer waits undefinitely for a connection, but exits instead. So this is an improvement, even if this does not fully match what this bug is requesting.

Comment 25 Daniel Berrangé 2017-05-04 15:56:05 UTC
So there's two separate issues here really. This bug addressed the GTK-VNC portion of the fix, which ensures we abort the connection with an error when connecting to SPICE. This is happening, as evidenced by fact that remote-viewer exits, instead of hanging forever.

Separately though, remote-viewer needs fixing to be able to actually report error messages from GTK-VNC. The recently released GTK-VNC introduced a new 'vnc-error' signal that provides the error message, which remote-viewer needs to handle.

I'm putting this back on QA since the GTK-VNC fix is done

Comment 26 Bill Sanford 2017-05-11 16:08:34 UTC
Verified that remote-viewer is closed and doesn't hang.

Comment 27 errata-xmlrpc 2017-08-01 19:55:38 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2258


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