[syslinux] tftpd: don't use AI_ADDRCONFIG to resolve addresses to bind(2)

[Ron]

On Sat, Feb 04, 2017 at 11:28:08PM +0100, Uwe Kleine-König wrote:
> On Sat, Feb 04, 2017 at 03:46:46PM +1030, Ron wrote:
> > > [...]
> > That would seem to be a pretty good summation of how we're failing to
> > converge here ...
> 
> I mixed too many things that IMHO improve the code but actually only
> care about one of those. So I suggest we restart the discussion with
> focusing on that one thing only.

Just repeating the same things, while ignoring the options I've shown
you that do properly fix the problem(s) you're claiming to care about,
isn't actually advancing this toward a workable solution in any way.
My previous replies to you were already focussed on the part of your
patch that removed AI_ADDRCONFIG, and why it was not needed at best,
and harmful at worst.

I can read the actual code, and understand how gai works, and I'm pretty
sure Mike understood all of that too when he first reported this bug.
I'd already long ago checked that there wasn't a real bug being triggered
somewhere here, and that the code itself really was working as expected,
and you haven't indicated anything to the contrary here.

In the subset of cases where gai is used to resolve a string into a
(set of) network address(es), it is not wrong to tell it that it's
useless to return any address (family) which can't possibly work with
the current machine configuration/state.

That doesn't become less wrong if your expectation or interpretation of
how it should work is different to reality and the specification of how
it is defined to work.  If you explicitly say "bind to 0.0.0.0", you're
saying you want to service global IPv4 requests.  If you have no global
IPv4 interfaces, that should fail and warn the admin of a problem, not
silently ignore that what they explicitly requested isn't going to work.


If what you meant to request was "bind to whatever *is* there, I don't
care what", then just don't pass an explicit address.

If you're allergic to that possibly also binding to IPv6 addresses,
then pass the -4 flag too.

We don't need to disable the sanity check for users who do configure
an explicit address for you to get the behaviour you say you want
from the current code, without any change to it at all.


If what you care about is "faster boot", then the answer to that isn't
"speculatively start things that will fail (or just be useless) if they
lose a race", it's to actually not waste time and resources doing that
until their known prerequisites have been satisfied.


Where it is expected that the available interfaces and/or configured
addresses might change dynamically long after boot, then whatever you
have doing that needs to notify, or reload, or (re)start, (or stop),
anything you are or want to be (not) running, based on that new state
of the system.

If you want that, propose a patch to add a hook.  Otherwise, what you
say you want is already possible without needing the kludge you did
send.


The only bit I'm still struggling to understand, is why you are still
pushing this patch hard instead of using what is already available that
has exactly the behaviour you say you desire, or looking at a more
complete and working solution for dynamic interfaces in general.

The options here and the actions of the code don't look very complicated
to me, so you don't need to "simplify" it on my behalf.  I'm just not
seeing you show any new problem that isn't contrived and that doesn't
already have a good and/or already working solution which doesn't depend
on needing this patch.

What problem isn't satisfied by the options I've shown above and earlier?

  Ron