Bug 12381

Summary: FEATURE_PREFER_IPV4_ADDRESS documentation misleading, behavior harmful
Product: Busybox Reporter: bugdal
Component: NetworkingAssignee: unassigned
Status: NEW ---    
Severity: normal CC: busybox-cvs, nico-linux-busybox
Priority: P5    
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Host: Target:
Build:

Description bugdal 2019-12-05 17:38:37 UTC
The str2sockaddr function that conditions its behavior on FEATURE_PREFER_IPV4_ADDRESS only returns a single address, so rather than just preferring IPv4, having this feature enabled makes it so that Busybox networking utils do not work at all on hosts without IPv4 connectivity. The effect is almost the same as passing AF_INET to getaddrinfo, except in the (presently very rare) case where a hostname has only AAAA records, no A records).

FEATURE_PREFER_IPV4_ADDRESS is documented as working around the order the DNS returns results in, which makes it sound like something useful users may want to enable, but the order of results is actually determined by getaddrinfo, not by the DNS. And decent getaddrinfo implementations (per RFC 3484 and its successor RFC 6724) already order the results based on routability, so that IPv4 addresses already apppear before v6 ones unless the v6 ones are routable over a real (non-tunnel) IPv6 network.

IMO the documentation for this config switch should be changed to clarify that it's a workaround for deficient getaddrinfo implementations, not for DNS behavior, and the default setting should be changed to n. Unless the whole BB networking framework is overhauled to try a list of fallbacks like getaddrinfo returns, rather than a single result like str2sockaddr presently does, FEATURE_PREFER_IPV4_ADDRESS is actively breaking things.