Bug 858232 - if port (tls-port) number is zero, treat it as if no port number given
Summary: if port (tls-port) number is zero, treat it as if no port number given
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-gtk
Version: 6.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: beta
: ---
Assignee: Marc-Andre Lureau
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-18 11:40 UTC by David Jaša
Modified: 2013-02-21 08:49 UTC (History)
6 users (show)

Fixed In Version: spice-gtk-0.14-5.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 08:49:09 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0343 0 normal SHIPPED_LIVE spice-gtk bug fix and enhancement update 2013-02-20 20:53:54 UTC

Description David Jaša 2012-09-18 11:40:14 UTC
Description of problem:
if port (tls-port) number is zero, treat it as no port number given.

This gives unnecessary network roundtrips to migration when only secure port is used on the destination.

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


How reproducible:


Steps to Reproduce:
0. have a x509_DIR
1. run source qemu:
qemu-kvm -monitor stdio -spice tls-port=SPORT1,x509_dir=DIR,disable-ticketing
2. run destination qemu:
qemu-kvm -monitor stdio -spice tls-port=SPORT2,x509_dir=DIR,disable-ticketing
3. connect to the source qemu:
remote-viewer --spice-ca-file DIR/ca-cert.pem spice://my-laptop.example.com/?tls-port=SPORT1
4. instruct source qemu to migrate the client with zero port:
__com.redhat_spice_migrate_info my-laptop.example.com 0 SPORT2 "host subject"
  
Actual results:
spice-gtk tries to connect to port 0:
channel-main.c:1717 migrate_begin 25 my-laptop.example.com 0 SPORT2
channel-main.c:1578 migrate_channel_connect 1:0
spice-channel.c:126 main-1:0: spice_channel_constructed
spice-session.c:1628 new main channel, switching
spice-channel.c:2255 Open coroutine starting 0x2103460
spice-channel.c:2098 Started background coroutine 0x21034e8 for main-1:0
spice-channel.c:2122 connection failed, trying with TLS port

Expected results:
spice-gtk skips port and goes to TLS port right away

Additional info:

Comment 1 Christophe Fergeau 2012-09-18 12:08:40 UTC
I don't think it attempts an non-SSL connection actually, the message comes from spice-channel.c:

reconnect:
    c->sock = spice_session_channel_open_host(c->session, channel, c->tls);
    if (c->sock == NULL) {
        if (!c->tls) {
            CHANNEL_DEBUG(channel, "connection failed, trying with TLS port");
            c->tls = true; /* FIXME: does that really work with provided fd */
            goto reconnect;
        } else {
            CHANNEL_DEBUG(channel, "Connect error");
            emit_main_context(channel, SPICE_CHANNEL_EVENT, SPICE_CHANNEL_ERROR_CONNECT);
            goto cleanup;
        }
    }

The actual connection is done in spice_session_channel_open_host from spice-session.c which starts with

    if ((use_tls && !s->tls_port) || (!use_tls && !s->port))
        return NULL;

c->tls and use_tls are FALSE or "connection failed, trying with TLS port" wouldn't appear, and s->port is null as well, so NULL is returned before any connection is attempted.

Comment 2 Marc-Andre Lureau 2012-10-18 13:23:11 UTC
sent to ML

   channel: improve debugging message
    
    The open_host() can return FALSE when the connection is discarded or
    skipped. Improve the message to not indicate a failure.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=858232

Comment 3 Marc-Andre Lureau 2012-12-10 13:01:53 UTC
in spice-gtk-0.14-5.el6

Comment 7 errata-xmlrpc 2013-02-21 08:49:09 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.

http://rhn.redhat.com/errata/RHBA-2013-0343.html


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