From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13008 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: getaddrinfo(3) / AI_ADDRCONFIG Date: Mon, 9 Jul 2018 20:59:43 -0400 Message-ID: <20180710005943.GT1392@brightrain.aerifal.cx> References: <20180709223805.GS1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1531184275 30718 195.159.176.226 (10 Jul 2018 00:57:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Jul 2018 00:57:55 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13024-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jul 10 02:57:51 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fcgyS-0007s6-WF for gllmg-musl@m.gmane.org; Tue, 10 Jul 2018 02:57:49 +0200 Original-Received: (qmail 10105 invoked by uid 550); 10 Jul 2018 00:59:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 10086 invoked from network); 10 Jul 2018 00:59:56 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13008 Archived-At: On Mon, Jul 09, 2018 at 08:11:48PM -0400, Christopher Friedt wrote: > > getaddrinfo is routable. The more likely thing an application might > > want is to request whichever result is routable > > ^^ > PRECISELY > > > want is to request whichever result is routable, but THAT ALREADY > > HAPPENS without AI_ADDRCONFIG: the results are sorted such that > > In fact IT DOES NOT ALREADY HAPPEN. Musl's getaddrinfo does not > provide a routable socket at all in the example I provided. In fact, > there are exactly zero network interfaces with an IPv6 address in this > case, but somehow musl comes back with "::1" for localhost, which is > more damaging than useful in this use case. You could almost say that > musl is currently also non-conformant in that sense. > > > routable ones come before non-routable ones, so if you try them in > > order, you'll never hit a non-routable address family unless all the > > results for the other family fail to be reachable. > > Want proof? Download the tarball I provided here: > https://issues.apache.org/jira/browse/THRIFT-4594 > [...] > So there you have it. A use case with a demonstrated bug and fix that > is 100% reproducible. Can you provide a minimized test case (short single C source file) to reproduce this, or an strace log of the test that fails? The latter is probably actually be better if the behavior is dependent on the Docker network configuration. Assuming the test is attempting to lookup and bind on "localhost" by name, which is what it appears to be doing here: https://github.com/apache/thrift/blob/82ae9575cdc112088771fc7b876f75e1e4d85ebb/lib/cpp/test/TServerSocketTest.cpp the behavior you're experiencing is not what I expect from musl; rather my expectation is that you would get 127.0.0.1 as the first result and ::1 as the second, and this is exactly what I see if I do: ip addr del ::1 dev lo on my laptop running Alpine, then call getaddrinfo for localhost with a small test program. The logic to sort results does gratuitously depend on v4mapped addresses working to do the IPv4 routability probing; if something about the configuration suppresses their ability to work, it will break. This is a known open issue I want to go back and fix. Seeing the strace would show me right away if it's the source of your problem, and even if not chances are very good that it would point out whatever the cause is. > > So at this point my leaning is somewhere between: > > > > 1. Saying it's 2018 and having a system without IPv6 support (at least > > ::1) is an unsupported configuration. > > That's a slippery-slope argument. Just because a system supports IPv6 > does not imply that a network interface needs to be configured with an > IPv6 address. As an example, my lame cable ISP does not route IPv6 > traffic nor does it provide an IPv6 prefix. Right. But unless you actively suppress it you'll have ::1 and link-local IPv6 addresses, which would cause AI_ADDRCONFIG to produce IPv6 results. > They are IPv4-only (you > may think I live in the dark ages). Therefore, it does not even make > sense for the average customer to configure IPv6 on their LAN. Does my > OS support IPv6? Of course. ... Did I bypass them with a 6in4 tunnel - > you can be damn sure ;-) But many people wouldn't bother with that. > > > 2. Implementing AI_ADDRCONFIG as detection for the case where IPv6 has > > been completely disabled at the kernel or container level. > > That's not at all the case here. > > 3. Where a user's OS supports IPv6 but they have simply opted not to > assign an IPv6 address to their network interface or use a link-local > address. AI_ADDRCONFIG is not designed to help you here, but getaddrinfo already does help you (with or without passing that flag) by sorting results by routability. Rich