[Bug 12381] New: FEATURE_PREFER_IPV4_ADDRESS documentation misleading, behavior harmful

bugzilla at busybox.net bugzilla at busybox.net
Thu Dec 5 17:38:37 UTC 2019


            Bug ID: 12381
           Summary: FEATURE_PREFER_IPV4_ADDRESS documentation misleading,
                    behavior harmful
           Product: Busybox
           Version: unspecified
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Networking
          Assignee: unassigned at busybox.net
          Reporter: bugdal at aerifal.cx
                CC: busybox-cvs at busybox.net
  Target Milestone: ---

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

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.

You are receiving this mail because:
You are on the CC list for the bug.

More information about the busybox-cvs mailing list