Bug 827115 - support link-local ipv6 addresses
support link-local ipv6 addresses
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-gtk (Show other bugs)
6.3
Unspecified Unspecified
high Severity low
: beta
: 6.8
Assigned To: Christophe Fergeau
SPICE QE bug list
: Regression
Depends On: 859474
Blocks: 880347 960054 1056252 840699
  Show dependency treegraph
 
Reported: 2012-05-31 12:17 EDT by David Jaša
Modified: 2015-10-19 05:01 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-19 05:01:28 EDT
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)
Workaround for the spice-gtk bug (5.32 KB, patch)
2012-09-26 04:37 EDT, Christophe Fergeau
no flags Details | Diff

  None (edit)
Description David Jaša 2012-05-31 12:17:50 EDT
Description of problem:
support link-local ipv6 addresses

Version-Release number of selected component (if applicable):
spice-gtk-0.11-10.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. have a VM that listens on ipv6
2. connect to the VM via link-local address: fe80::1122:33ff:fe44:5566%if
(substitute 11, 22, 33, 44, 55, 66 with actual mac address bytes and if with interface name)
3.
  
Actual results:
connection fails

Expected results:
client connects

Additional info:
tested on spicec and spicy in CLI and on spicec and remote-viewer via controller. spicec works in all cases, spice-gtk-based clients don't work at all -> marking as a regression.
Comment 2 David Jaša 2012-06-14 05:45:48 EDT
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
Comment 3 Christophe Fergeau 2012-09-19 04:48:02 EDT
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
Comment 4 Christophe Fergeau 2012-09-19 16:56:32 EDT
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.
Comment 5 Christophe Fergeau 2012-09-21 11:43:37 EDT
(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.
Comment 6 David Jaša 2012-09-21 12:08:28 EDT
(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.
Comment 7 Christophe Fergeau 2012-09-26 04:37:23 EDT
Created attachment 617460 [details]
Workaround for the spice-gtk bug
Comment 8 Christophe Fergeau 2012-09-26 04:39:39 EDT
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.
Comment 9 David Blechter 2012-10-05 08:21:53 EDT
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
Comment 12 David Jaša 2012-11-23 07:12:10 EST
(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?
Comment 13 Pavel Šimerda (pavlix) 2012-11-23 10:13:30 EST
(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.
Comment 14 Christophe Fergeau 2012-11-23 10:24:49 EST
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
Comment 15 Christophe Fergeau 2012-11-23 10:34:41 EST
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
Comment 16 Pavel Šimerda (pavlix) 2012-11-28 15:45:11 EST
(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.
Comment 17 Christophe Fergeau 2013-05-16 07:47:06 EDT
(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@gnome.org>
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.
Comment 18 Christophe Fergeau 2013-05-16 08:45:22 EDT
(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.
Comment 19 Dan Winship 2013-05-16 09:13:44 EDT
(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.)
Comment 20 David Jaša 2013-05-16 09:23:44 EDT
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
Comment 21 David Jaša 2013-05-16 09:25:56 EDT
forgot to add: m-r-v stays in stage with black screen with "Connecting to graphic server" message
Comment 22 Christophe Fergeau 2013-05-16 10:07:28 EDT
(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.
Comment 23 Christophe Fergeau 2013-05-21 11:47:23 EDT
(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
Comment 24 Christophe Fergeau 2013-05-24 09:33:07 EDT
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.
Comment 25 David Blechter 2013-05-28 10:15:12 EDT
Devel Cond Nack based on the "depend on" bug was not even proposed for the current/future releases.
Comment 27 Marc-Andre Lureau 2014-02-28 07:40:25 EST
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)
Comment 28 Christophe Fergeau 2014-02-28 07:55:01 EST
POST would probably make sense until someone pushes for it. Hopefully it's working in RHEL7.

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