GNOME Bugzilla – Bug 684404
When using g_network_address_address_enumerator_next(), ipv6 scope id is lost
Last modified: 2018-05-24 14:37:28 UTC
Created attachment 224782 [details] test case See attached test case, I've been trying to use g_network_address_new() with an ipv6 address like fe80::xxxx:xxff:fexx:xxxx%em1 (link-local address I picked in ifconfig followed by the interface name), but this does not work as expected, the scope id is lost on the way :-/
as a workaround, you should be able to parse that into a struct sockaddr yourself, then call g_socket_address_new_from_native(), and use the GSocketAddress as your GSocketConnectable rather than creating a GNetworkAddress.
This is exactly why we have getaddrinfo() as the system library to resolve network names. Anything in the upper layers should be using getaddrinfo() for host and service resolution.
Created attachment 231379 [details] [review] GInetSocketAddress: fix the byte order of flowinfo and scope_id The flowinfo and scope_id fields of struct sockaddr_in6 are in host byte order, but the code previously assumed they were in network byte order. Fix that. This is an ABI-breaking change (since before you would have had to use g_ntohl() and g_htonl() with them to get the correct values, and now that would give the wrong values), but the previous behavior was clearly wrong (no other gio methods work in network byte order), so anyone who worked around it rather than reporting it as a bug deserves to lose.
Created attachment 231380 [details] [review] gnetworkaddress: preserve IPv6 scope ID in IP literals If a GNetworkAddress is created with a hostname like "fe80::xxx%em1", make sure that the scope_id corresponding to "em1" is present in the GSocketAddresses it returns when used as a GSocketConnectable.
(In reply to comment #3) > but the previous behavior was > clearly wrong (no other gio methods work in network byte order), so > anyone who worked around it rather than reporting it as a bug deserves > to lose. This is up for argument, although the alternative option sucks...
(In reply to comment #5) > (In reply to comment #3) > > but the previous behavior was > > clearly wrong (no other gio methods work in network byte order), so > > anyone who worked around it rather than reporting it as a bug deserves > > to lose. > > This is up for argument, although the alternative option sucks... Hm, so it's been that way since 2.32? That's two stable releases, which argues for compatibility. But OTOH, if we don't know of any other apps using the API besides yours (what is your app?), that argues for fixing it. Personally I'd lean towards fixing it.
(In reply to comment #6) > Hm, so it's been that way since 2.32? That's two stable releases, which argues > for compatibility. But OTOH, if we don't know of any other apps using the API > besides yours (what is your app?) I don't have an app using this, and presumably Christophe doesn't either given this bug report. I've pinged the filer of bug 635554 which was the original bug that led to it being added... (grumble grumble lack of google code search)
The code that triggered this bug report is http://cgit.freedesktop.org/spice/spice-gtk/tree/gtk/spice-session.c#n1611 , I don't think this would be impacted by the change you suggest.
(In reply to comment #4) > Created an attachment (id=231380) [details] [review] > gnetworkaddress: preserve IPv6 scope ID in IP literals > > If a GNetworkAddress is created with a hostname like "fe80::xxx%em1", > make sure that the scope_id corresponding to "em1" is present in the > GSocketAddresses it returns when used as a GSocketConnectable. That smells. We have 'getaddrinfo()' for a reason, even if it has bugs.
(In reply to comment #9) > That smells. We have 'getaddrinfo()' for a reason which is why the patch uses getaddrinfo()...
(In reply to comment #10) > (In reply to comment #9) > > That smells. We have 'getaddrinfo()' for a reason > > which is why the patch uses getaddrinfo()... I missed this. Thanks for explanation.
following up from IRC: we will eventually want to be able to deal with the case where someone tries to connect to "foo.local", which resolves via mdns to "fe80:...%em1". GResolver only has 3 more expansion slots, so if we added lookup_by_name_and_return_sockaddrs() plus async, we'd be out... but we could just hack around it by using lookup_records() maybe? (The patch here is still an improvement for now.)
Some information here: https://fedoraproject.org/wiki/Features/ZeroconfNetworking This feature page will be improved over the time.
What is the consensus here ? I'm not opposed to fixing the byte order thing - just add a note about it to README.in.
If you're ok with it I say we should push the byte order fix. README.in note: +* The 'flowinfo' and 'scope_id' fields of GInetSocketAddress + (introduced in GLib 2.32) have been fixed to be in host byte order + rather than network byte order. This is an incompatible change, but + the previous behavior was clearly broken, so it seems unlikely that + anyone was using it. (as for the other patch, I think we should push it if and only if we're not going to get the better fix from comment 12 in before 2.36. And I think we can get that better fix in, so I'll hold off on this for a bit.)
Comment on attachment 231379 [details] [review] GInetSocketAddress: fix the byte order of flowinfo and scope_id pushed the byte order fix but still not yet the other fix
Comment on attachment 231380 [details] [review] gnetworkaddress: preserve IPv6 scope ID in IP literals Pushed the other attachment, but leaving this bug open to track the fact that we eventually want to fix this at the GResolver level (at which point the GNetworkAddress-specific hack can be removed). Attachment 231380 [details] pushed as 8a77f7b - gnetworkaddress: preserve IPv6 scope ID in IP literals
Adjusting component to gio in preparation for GitLab migration
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/607.