GNOME Bugzilla – Bug 526321
Doesn't try all address returned by getaddrinfo
Last modified: 2010-08-14 20:51:54 UTC
Hi, getaddrinfo returns multiple addresses, but libsoup only uses the first one. This is a problem if the remote host has both an ipv6 and ipv4 address. In that case the first address is the ipv6 address.. If you host doesn't support ipv6 or the remote http server doesn't listen on ipv6, the connection will fail and libsoup won't fall back to the next address.. What it should do is to try all addresses returned by getaddrinfo one by one untill connecting to one succeeds. This fixes the issue of hostnames resolving to unsupported address families and makes soup more reliable if a name points to multiple servers of which one has died..
(In reply to comment #0) > getaddrinfo returns multiple addresses, but libsoup only uses the first one. > This is a problem if the remote host has both an ipv6 and ipv4 address. In that > case the first address is the ipv6 address.. If you host doesn't support ipv6 > or the remote http server doesn't listen on ipv6, the connection will fail libsoup was supposed to be passing the AI_ADDRCONFIG flag to getaddrinfo, so that it wouldn't return IPv6 addresses if you didn't have an IPv6 address configured. Unfortunately, there was a bug such that it wasn't passing that flag. That's fixed in trunk/2.4.1, but it turns out to now help much, because it only checks if you have an IPv6 *address*, not if you actually have IPv6 *routing*, so even a link-local IPv6 address is enough to make it return IPv6 addresses. BTW, for me, getaddrinfo tends to return IPv4 addresses first. Eg: danw@blorple:tests> host www.ietf.org www.ietf.org has address 64.170.98.32 www.ietf.org has IPv6 address 2001:1890:1112:1::20 You get a different behavior? Are you on Linux or something else? At any rate, the bug report is correct; we *should* be trying all available addresses. This may not be easy to fix in the GNOME 2.22.x timeframe though.
host doesn't use getaddrinfo, it talks to DNS directly.. If you want to check what getaddrinfo returns you need to use getent: $ getent ahosts www.ietf.org 2001:1890:1112:1::20 STREAM www.ietf.org 2001:1890:1112:1::20 DGRAM 2001:1890:1112:1::20 RAW 64.170.98.32 STREAM 64.170.98.32 DGRAM 64.170.98.32 RAW Right, with support ipv6 i meant can connect to a global ipv6 address. Most distribution ship with ipv6 enabled by default, so one will probably always have a link-local ipv6 address
I still get IPv4 first: danw@blorple:~> getent ahosts www.ietf.org 64.170.98.32 STREAM www.ietf.org 64.170.98.32 DGRAM 64.170.98.32 RAW 2001:1890:1112:1::20 STREAM 2001:1890:1112:1::20 DGRAM 2001:1890:1112:1::20 RAW
I'm running Debian. In the end libc is responsible for how the sorting is done and this is configurable in /etc/gai.conf.. I've been using ipv6 for a long time and afaik the default always has been to sort ipv6 addresses first, but it might be that your distribution configures things differently..
By default (atleast in debian) ipv6 is sorted after ipv4 in case you have 6to4 (2002::) addresses, since there's no use to prefer a tunnel over native connection. This all depends on the /etc/gai.conf though as Sjoerd mentioned...
*** Bug 576473 has been marked as a duplicate of this bug. ***
*** Bug 590333 has been marked as a duplicate of this bug. ***
Also Gentoo with IPv6 is affected (the current network is not IPv6 enabled however). My glibc is 2.10.1. I have nothing in /etc/gai.conf. I cannot find a patch which might have affect in-glibc handling.
*** Bug 600572 has been marked as a duplicate of this bug. ***
Wow! Finally, problem solved! I've been having trouble since the upgrade to Ubuntu 9.10 with Epiphany WebKit not resolving "localhost" addresses correctly. Also, web page loading has been unusually slow and I thought it was my network. I just edited /etc/gai.conf and uncommented the lines pre-configured in the default file (including the line to prefer IPv4 over IPv6) and TADA it now works correctly AND FASTER! Yay!
I see this bug on my Fedora 12 laptop, and this may be related to the fact that I use suspend to ram and move from a ipv6 enabled network to a one without ipv6 ( but getent hosts still fetch ipv6 first, for some reason. Restarting nscd do not help ). So the problem is not limited to Debian or Gentoo.
I just ran into this bug as well. This is easily reproducible here (on Debian) using just the tests that ship with libsoup: ~~~~ TERMINAL 1 ~~~~ $ ./tests/simple-httpd Starting Server on port 2946 Waiting for requests... ~~~~ TERMINAL 2 ~~~~ $ ./tests/get http://localhost:2946/ /: 4 Cannot connect to destination $ curl -v http://localhost:2946/ * About to connect() to localhost port 2946 (#0) * Trying ::1... Connection refused * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 2946 (#0) .... Notice how soup fails to connect since it only tries to connect to the first address candidate, whereas curl tries both possibilities so it succeeds.
*** Bug 625632 has been marked as a duplicate of this bug. ***
fixed in master!