Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180714023134.GH1392@brightrain.aerifal.cx>
Date: Fri, 13 Jul 2018 22:31:34 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: getaddrinfo(3) / AI_ADDRCONFIG

On Thu, Jul 12, 2018 at 10:53:12PM -0400, Christopher Friedt wrote:
> On Thu, Jul 12, 2018 at 9:49 PM Rich Felker <dalias@...c.org> wrote:
> > Something's not going right with our communication about this. I've
> > attached an untested patch that's closer to what I've been looking
> > for. It corrects an oversight I'd made, that we need to block
> > cancellation during the probe, and localizes the change as originally
> > requested. Please let me know if it works. Arguably it might be nicer
> > to replace the repeated code with a table and 2-iteration for loop.
> 
> I originally wrote my patch with the intention of being as unobtrusive
> as possible but rather than disagree realized it was better to just do
> what you wanted me to.
> 
> The struct was a better solution for when the addrconfig logic lived
> in a separate function. It probably could have even been a separate
> static function inside of getaddrinfo.c, but I anticipated that you
> would not have liked that.
> 
> Definitely correct to disable pthread cancellation.
> 
> I used struct sockaddr_storage to avoid declaring more than one
> sockaddr because I thought you would have preferred that. Personally,
> I would have preferred to use two separate sockaddr too. Solves that
> problem.
> 
> Originally, I wanted to use a loop over the length of a table, but
> figured you would dislike that in favour of readability. Assuming
> there will only be ever be AF_INET and AF_INET6 support for
> getaddrinfo(3), handling it this or that way is fine.
> 
> The patch works for me as is or with the loop.

Here's a version with the loop. I've tested it now with ::1 removed
from device lo, but the connect to ::1 still succeeds; I suspect
presence of a default route for IPv6 makes it work since ::1 is
"routable" then. Can you confirm that it actually suppresses IPv6 in
your purely-no-IPv6 environment, as intended?

Rich

View attachment "ai_addrconfig2.diff" of type "text/plain" (1559 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.