From: Michael Stapelberg Date: Thu, 18 Aug 2011 19:38:28 +0000 (+0200) Subject: Drop AI_ADDRCONFIG when resolving TCP addresses X-Git-Url: http://git.demorecorder.com/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4f25ee16443b29e1a25bd26a724e1e0a577e21ff;hp=4f25ee16443b29e1a25bd26a724e1e0a577e21ff;p=free-sw%2Fxcb%2Flibxcb Drop AI_ADDRCONFIG when resolving TCP addresses When a system is completely offline (no interface has an IP address but 'lo'), xcb could not connect to localhost via TCP, e.g. connections with DISPLAY=127.0.0.1:0 fail. AI_ADDRCONFIG will only return IPv4 addresses if the system has an IPv4 address configured (likewise for IPv6). This also takes place when resolving localhost (or 127.0.0.0/8 or ::1). Also, as per RFC 3493, loopback addresses are not considered as valid addresses when determining whether to return IPv4 or IPv6 addresses. As per mailing-list discussion on the xcb list started with message 20110813215405.5818a0c1@x200, the AI_ADDRCONFIG flag is there for historical reasons: In the old days, the "default on-link" assumption in IPv6 made the flag vey much indispensable for dual-stack hosts on IPv4-only networks. Without it, there would be long timeouts trying non-existent IPv6 connectivity. Nowadays, this assumption has been flagged as historic bad practice by IETF, and hosts should have been updated to not make it anymore. Then AI_ADDRCONFIG became mostly cosmetic: it avoids phony "Protocol family not supported" or "Host unreachable" errors while trying to connect to a dual- stack mode from a host with no support for source address selection. Nowadays, on up-to-date systems, this flag is completely useless. Then again, I understood only the very latest MacOS release is "up-to-date" with this definition. ---