On Tue, 13 Oct 2020 at 13:10:46 +0000, Paul Wise wrote: > On Tue, Oct 13, 2020 at 11:12 AM Simon McVittie wrote: > > Or is there anything odd about arm-conova-03's TCP or other networking > > setup? > > arm-conova-03 does not have an IPv4 address/route except on the > loopback device but amdahl, arm-conova-01 and arm-conova-02 do.
Thanks, that could well be it. libdbus resolves the host part of a TCP address using getaddrinfo() with AI_ADDRCONFIG, but AI_ADDRCONFIG has troublesome behaviour on systems where the only IPv4 address is loopback (reported years ago as <https://bugs.debian.org/854302>, for example). The intended behaviour of AI_ADDRCONFIG (I think) is to make, for example, example.com resolve to an IPv6 address if you only have external IPv6 connectivity, an IPv4 address if you only have external IPv4 connectivity, or both if you have both. This makes complete sense if you are connecting to arbitrary Internet hosts, or even to LAN hosts, but is actively hostile if you happen to be "talking to yourself" in a unit test by connecting to ::1, 127.x.x.x or localhost, which (as in this case) are very likely to be reachable via IPv4 or IPv6 even if nothing else is. Recent versions of GLib implement https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02, and also implement a special case that attempts to parse hostnames as IPv4 or IPv6 addresses before trying name resolution; but libdbus doesn't have either of those yet (partly because D-Bus over TCP is insecure and discouraged, so I don't want to spend time improving it). See also <https://bugs.debian.org/952740>, <https://sourceware.org/bugzilla/show_bug.cgi?id=12398>. smcv
