This is http://bugs.debian.org/658616 , initially reported about wget but it is seemingly more generic than wget. Apparently when getaddrinfo() returns a v6 addresss before v4 one, and the host from which we're trying to connect does not have v6 routing, the connection fails. As far as I can see, this is due to str2sockaddr() function returning only first address, even if it uses getaddrinfo() which returns a list. Next that single address gets passed to connect routine which, on a v6-enabled-but-not-configured host will fail.
Created attachment 4730 [details] add-AI_ADDRCONFIG-to-fix-ipv4-DNS-errors-with-ipv6.patch
The error is actually a bit more subtle than what Michael has posted, but he pointed me in the right area to look at, so thanks! tl;dr fix: pass AI_ADDRCONFIG as a hint flag to getaddrinfo. RFC 2553 states: The AI_ADDRCONFIG flag specifies that a query for AAAA records should occur only if the node has at least one IPv6 source address configured and a query for A records should occur only if the node has at least one IPv4 source address configured. -- What seems to be happening, as far as I can tell: (Sorry for the intense detail!) getaddrinfo is returning not found, since it tries an IPV6 lookup, but with only a link-local address, it fails. If hints is NULL, then getaddrinfo should use the default (specified in RFC2553), (AI_V4MAPPED|AI_ADDRCONFIG). However, str2sockaddr is building hints manually since af is passed in to choose IPv4/IPv6, and also for ai_flags which are used in the *2sockaddr functions and the busybox-specific DIE_ON_ERROR support (and a faster path for AI_NUMERICHOST.) This then doesn't include AI_ADDRCONFIG. I have attached a patch to apply AI_ADDRCONFIG if it is available. This has eliminated the 'Bad address' issues with wget for my test case. I have only tested it on a v4-IP only host (with v6 support in the kernel/glibc/busybox) that is experiencing the same random failures in wget. Since it is the default value for when there hints is NULL however there shouldn't be any side effects. Environment is Yocto "danny" on armv7a: busybox-1.20.2, eglibc-2.16, linux-2.6.37. Patch applies to latest git HEAD (30a8652f).
Did you try to ENABLE_FEATURE_PREFER_IPV4_ADDRESS in .config?
(In reply to comment #3) > Did you try to ENABLE_FEATURE_PREFER_IPV4_ADDRESS in .config? Yes, CONFIG_FEATURE_PREFER_IPV4_ADDRESS=y has always been set.
(In reply to comment #4) > (In reply to comment #3) > > Did you try to ENABLE_FEATURE_PREFER_IPV4_ADDRESS in .config? > > Yes, CONFIG_FEATURE_PREFER_IPV4_ADDRESS=y has always been set. Then it has to use IPv4 in the situation described in 1st comment: "Apparently when getaddrinfo() returns a v6 addresss before v4 one, and the host from which we're trying to connect does not have v6 routing, the connection fails. As far as I can see, this is due to str2sockaddr() function returning only first address..." Relevant code from busybox-1.19.4/libbb/xconnect.c: str2sockaddr(...) { ... rc = getaddrinfo(host, NULL, &hint, &result); if (rc || !result) { ...error... } used_res = result; #if ENABLE_FEATURE_PREFER_IPV4_ADDRESS while (1) { if (used_res->ai_family == AF_INET) break; used_res = used_res->ai_next; if (!used_res) { used_res = result; break; } } #endif Can you debug why it doesn't work as intended?
(In reply to comment #5) > > Can you debug why it doesn't work as intended? Yes, I should have added that earlier: Without the patch applied, the call to getaddrinfo returns: EAI_NODATA (-5) No address associated with NAME. and doesn't provide any responses at all (result is NULL as well.)
Comment on attachment 4730 [details] add-AI_ADDRCONFIG-to-fix-ipv4-DNS-errors-with-ipv6.patch do not use, does not apply.
(In reply to comment #6) > (In reply to comment #5) > > > > Can you debug why it doesn't work as intended? > > Yes, I should have added that earlier: > > Without the patch applied, the call to getaddrinfo returns: > > EAI_NODATA (-5) No address associated with NAME. > > and doesn't provide any responses at all (result is NULL as well.) Sorry for the noise, while my proposed patch does work for my test case, it is only a workaround for another issue I am having with glibc. So, please don't use my patch unless you want a certain level of breakage... https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG Also, I believe Michael is describing a separate issue which may be valid in its own right. Thanks for the help, Denys and Paul.
Hello, I am experiencing this problem in the other way around - tftp fails to connect to V6-and-V4 targets from my V6-only box. The use of AI_ADDRCONFIG, as proposed by Kevin, addressed that problem, and at least in my configuration (busybox 1.23, glibc 2.22, linux ARM 4.1.12) I could not identify any side effect. Is there any plan to revisit Kevin's patch? https://bugs.busybox.net/attachment.cgi?id=4730