Bug 827115

the bug seems to be entirely on spice-gtk, when launch the virt-viewer by pointing it to link-local IP of the hypervisor, it will connect without issues (provided that spice-server will listen on all addresses):

virt-viewer -c qemu+tcp://[link-local-ipv6]/system VM_NAME

I can reproduce this with these steps:

- edit an existing libvirt VM (virsh dumpxml + virsh define) so that the 'graphics' element is

    <graphics type='spice' autoport='yes' listen='::0'>              
      <listen type='address' address='::0'/>                               
    </graphics>

- start the VM
- get the link-local address of one of your net interfaces (em1, wlan0, ...) ('ipv6' field in 'ip -6 addr show dev em1')

- run "spicec -p 5900 -h $address%$interface" (something like fe80::1122:33ff:fe44:5566%if mentioned in the first comment)
-> this works 

- run "remote-viewer spice://[$address%$interface]:5900"
-> this does not work

There are multiple bugs there. The first one is caused by spice_uri_parse() calling g_uri_unescape_string() on its argument, but virt_viewer_session_spice_open_uri() sets a non-escaped URI on its SpiceSession.
Then this does not work because of issues with scope zone id (the %em1) in glib, see https://bugzilla.gnome.org/show_bug.cgi?id=684404 .
The glib2 RHEL package will probably be impacted by https://bugzilla.gnome.org/show_bug.cgi?id=635554 as well.

I'm under the impression that using %em1 is ipv6 addresses is not very common, so I'm not sure getting this to work perfectly is urgent.

(In reply to comment #4)
> There are multiple bugs there. The first one is caused by spice_uri_parse()
> calling g_uri_unescape_string() on its argument, but
> virt_viewer_session_spice_open_uri() sets a non-escaped URI on its
> SpiceSession.

This one's fixed in spice-gtk-0.14-1.el6

> Then this does not work because of issues with scope zone id (the %em1) in
> glib, see https://bugzilla.gnome.org/show_bug.cgi?id=684404 .
> The glib2 RHEL package will probably be impacted by
> https://bugzilla.gnome.org/show_bug.cgi?id=635554 as well.
> 

but things are still not working because of this one. This bug could be reassigned to glib, or it could be cloned, and this one marked as fixed.

(In reply to comment #5)
> > Then this does not work because of issues with scope zone id (the %em1) in
> > glib, see https://bugzilla.gnome.org/show_bug.cgi?id=684404 .
> > The glib2 RHEL package will probably be impacted by
> > https://bugzilla.gnome.org/show_bug.cgi?id=635554 as well.
> > 
> 
> but things are still not working because of this one. This bug could be
> reassigned to glib, or it could be cloned, and this one marked as fixed.

I've created downstream bug for glib issue and made this one depend on it to get things proprerly tracked.

Created attachment 617460 [details]
Workaround for the spice-gtk bug

This patch workarounds the glib bug linked above, but I won't push it upstream as the fix belongs in glib. This can be considered for RHEL though.

The bug it depends on was not approved for 6.4 by PM https://bugzilla.redhat.com/show_bug.cgi?id=859474.
Set back devel_ack to "?" for 6.4

(In reply to comment #7)
> Created attachment 617460 [details]
> Workaround for the spice-gtk bug

Christophe, if I understand the C code correctly, AI_ADDRCONFIG flag would be set if available. I'd wait with such patch, because the flag (and its specification in RFC and POSIX) essentially block connection on localhost localhost when there's no external connectivity:
https://fedoraproject.org/wiki/Networking/NameResolution#Flag_AI_ADDRCONFIG_considered_harmful

Pavel, seeing that you're already CCd here, what's the best approach here? Will AI_ADDRCONFIG be made useful in forseeable future, or it should be unset?

(In reply to comment #12)
> Pavel, seeing that you're already CCd here, what's the best approach here?
> Will AI_ADDRCONFIG be made useful in forseeable future, or it should be
> unset?

Currently it is only harmful, not useful. I modified the page and now it offers the following solutions:

1) Ignore AI_ADDRCONFIG. As it has not been working for years and nobody cared enough to fix it, there is a substantial probability that it's not needed. Remove the code that implements it.

2) Patch software to avoid using AI_ADDRCONFIG and follow new deveopment, and periodically check whether someone put it back.

3) Only process AI_ADDRCONFIG in the nsswitch DNS plugin. This requires implementing getaddrinfo() in nsswitch which is required for zeroconf networking anyway. Use solution (1) as a temporary fix.

As #1 has not yet been aproved, and #3 will certainly not be available soon, the
only solution is #2.

Don't use AI_ADDRCONFIG. It doesn't solve the problems it was made for. It
creates problems that are not easy to spot.

glib is using AI_ADDRCONFIG, I guess it should be fixed if it's that bad... http://git.gnome.org/browse/glib/tree/gio/gresolver.c#n159

apr also uses it, but it seems to try to workaround AI_ADDRCONFIG limitations https://svn.apache.org/viewvc/apr/apr/trunk/network_io/unix/sockaddr.c?r1=1341196&r2=1343233
nspr seems to be using it, and has the same kind of workarounds https://hg.mozilla.org/releases/mozilla-1.9.2/rev/c5d74bcd7421

(In reply to comment #14)
> glib is using AI_ADDRCONFIG, I guess it should be fixed if it's that bad...
> http://git.gnome.org/browse/glib/tree/gio/gresolver.c#n159

(In reply to comment #15)
> apr also uses it, but it seems to try to workaround AI_ADDRCONFIG
> limitations
> https://svn.apache.org/viewvc/apr/apr/trunk/network_io/unix/sockaddr.
> c?r1=1341196&r2=1343233
> nspr seems to be using it, and has the same kind of workarounds
> https://hg.mozilla.org/releases/mozilla-1.9.2/rev/c5d74bcd7421

Thanks for information. Added to https://fedoraproject.org/wiki/Networking/NameResolution#Flag_AI_ADDRCONFIG_considered_harmful

For Linux, it would be enough to diable AI_ADDRCONFIG in glibc. It would be
possible to make it useful through moving its semantics to the DNS plugin.
Although it might still break when using using a local DNS server for locally
assigned global addresses.

(In reply to comment #6)
> I've created downstream bug for glib issue and made this one depend on it to
> get things proprerly tracked.

The glib bug has been fixed, but I needed

commit f4a188234105cb363aecaefd31e06e1f976200c0
Author: Dan Winship <danw>
Date:   Sun May 5 16:50:43 2013 -0400

    GProxyAddressEnumerator: add default-port property
    
    Although none of the in-tree GSocketConnectable types need it, other
    types (like SoupAddress) may find it useful to be able to pass a URI
    and a default-port to GProxyAddressEnumerator separately (the same way
    you can with GNetworkAddress). So add a default-port property.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=698877

in addition to it for things to work, and even with that I get warnings in the console about using an invalid URI even though it manages to connect to the VM.

(In reply to comment #17)
> I get warnings in
> the console about using an invalid URI even though it manages to connect to
> the VM.

I've filed https://bugzilla.gnome.org/show_bug.cgi?id=700455 for that.

(In reply to comment #17)
> The glib bug has been fixed, but I needed

>     GProxyAddressEnumerator: add default-port property

> in addition to it for things to work

That should only be relevant if you're implementing your own GSocketConnectable; GNetworkAddress was doing the right thing already.

(If you are implementing your own GSocketConnectable, you can work around the problem by just rewriting the URI to include the port.)

I can't say why but it doesn't work. Ports are reachable:

C:\Users\shadowman>ping -6 fe80::200:ff:fe00:0%11

Pinging fe80::200:ff:fe00:0%11 with 32 bytes of data:
Reply from fe80::200:ff:fe00:0%11: time<1ms
Reply from fe80::200:ff:fe00:0%11: time<1ms
Reply from fe80::200:ff:fe00:0%11: time<1ms
Reply from fe80::200:ff:fe00:0%11: time<1ms

Ping statistics for fe80::200:ff:fe00:0%11:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Users\shadowman>nmap -6 -p 5904,5905 --version-all fe80::200:ff:fe00:0%11

Starting Nmap 6.25 ( http://nmap.org ) at 2013-05-16 11:17 Coordinated Universal Time
Nmap scan report for fe80::200:ff:fe00:0
Host is up (0.00s latency).
PORT     STATE SERVICE
5904/tcp open  unknown
5905/tcp open  unknown
MAC Address: FE:54:00:26:89:62 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 0.70 seconds



but m-r-v can't connect (most recent messages first):

Classic 5/16/2013 11:18:44 AM   VirtViewer      2       None
GSpice: ../../gtk/spice-session.c:1760 open host fe80::200:ff:fe00:0%11:5904
Classic 5/16/2013 11:18:44 AM   VirtViewer      2       None
GLib-GIO: g_proxy_resolver_lookup_async: assertion `uri != NULL' failed
Classic 5/16/2013 11:18:44 AM   VirtViewer      2       None     
GLib-GIO: Invalid URI 'none://[fe80::200:ff:fe00:0%11]:5904'
Classic 5/16/2013 11:18:44 AM   VirtViewer      2       None
GSpice: ../../gtk/spice-session.c:1696 connecting 0446FEA8...
Classic 5/16/2013 11:18:44 AM   VirtViewer      2       None
GSpice: ../../gtk/spice-channel.c:2096 main-1:0: Started background coroutine 020DB0F4
Classic 5/16/2013 11:18:44 AM   VirtViewer      2       None 
GSpice: ../../gtk/spice-channel.c:2254 main-1:0: Open coroutine starting 020DB0B0
Classic 5/16/2013 11:18:44 AM   VirtViewer      2       None    
GSpice: ../../gtk/spice-gtk-session.c:468  ""UTF8_STRING"Classic        5/16/2013 11:18:44 AM   VirtViewer      2       None
GSpice: ../../gtk/spice-gtk-session.c:464 clipboard_get_targets:
Classic 5/16/2013 11:18:44 AM   VirtViewer      2       None
GSpice: ../../gtk/spice-gtk-session.c:809 Changing main channel from 00000000 to 020DB0B0
Classic 5/16/2013 11:18:44 AM   VirtViewer      2       None
GSpice: ../../gtk/spice-session.c:1830 main-1:0: new main channel, switching
Classic 5/16/2013 11:18:44 AM   VirtViewer      2       None
GSpice: ../../gtk/spice-channel.c:126 main-1:0: spice_channel_constructed
Classic 5/16/2013 11:18:44 AM   VirtViewer      2       None    
GSpice: ../../gtk/spice-session.c:1577 session: disconnecting 0
Classic 5/16/2013 11:18:44 AM   VirtViewer      2       None
GSpice: ../../gtk/usb-device-manager.c:853 device added 020959C8
Classic 5/16/2013 11:18:43 AM   VirtViewer      2       None    
GSpice: ../../gtk/spice-session.c:172 Supported channels: main, display, inputs, cursor, playback, record, smartcard, usbredir
Classic 5/16/2013 11:18:43 AM   VirtViewer      2       None    
GSpice: ../../gtk/spice-session.c:155 New session (compiled from package spice-gtk 0.14-dirty)
Classic 5/16/2013 11:18:43 AM   VirtViewer      2       None
remote-viewer: virt-viewer 0.5.3 started on Windows

forgot to add: m-r-v stays in stage with black screen with "Connecting to graphic server" message

(In reply to comment #19)
> (In reply to comment #17)
> > The glib bug has been fixed, but I needed
> 
> >     GProxyAddressEnumerator: add default-port property
> 
> > in addition to it for things to work
> 
> That should only be relevant if you're implementing your own
> GSocketConnectable; GNetworkAddress was doing the right thing already.

Oh, looking at it some more, this is just a side-effect of this commit.
Before, when the URI fails to parse (triggering g_warning ("Invalid URI '%s'", uri);), priv->dest_uri was not set.
After the change, the URI is no longer checked for validity when it's set, and only priv->dest_port will end up not being set if the URI is invalid.

Since the URI I'm setting fails to parse (this is what bgo#700455 is about), I guess that explains why I'm getting a different behaviour with/without this commit.

(In reply to David Jaša from comment #20)
> I can't say why but it doesn't work.

This is not working without https://bugzilla.gnome.org/show_bug.cgi?id=700455 or the commit mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=827115#c17

Tom, the correct fix for this bug belongs in glib, see bug #859474. As this bug is only a very specific cornercase ( fe80::1122:33ff:fe44:5566%em0 not working), I don't think it deserves us carrying a non-upstream patch in virt-viewer to workaround it unless this impacts customers.

Imo, this bug should not block #960054, #859474 should block it instead if this issue is deemed important enough.

Devel Cond Nack based on the "depend on" bug was not even proposed for the current/future releases.

David, Christophe

should we lower priority of this bug to better reflect the situation? Since there is a workaround patch attached, why not move it to POST/ASSIGNED? (that makes it clearer it's no longer in the "new/todo" list)

POST would probably make sense until someone pushes for it. Hopefully it's working in RHEL7.