[syslinux] Bug#771441: tftpd: don't use AI_CANONNAME and AI_ADDRCONFIG to resolve addresses for bind

[Ron]

On Fri, Feb 03, 2017 at 10:19:06AM +0100, Uwe Kleine-König wrote:
> On Fri, Feb 03, 2017 at 03:40:32PM +1030, Ron wrote:
> > On Thu, Feb 02, 2017 at 02:22:47PM +0100, Uwe Kleine-König wrote:
> > > On Thu, Feb 02, 2017 at 04:08:49PM +1030, Ron via Syslinux wrote:
> > >
> > > > The use of AI_PASSIVE here is a placebo.  That flag has no effect unless
> > > > address was NULL, and if that was true, neither of the hunks here would
> > > > actually be executed in the first place.
> > > 
> > > Right. Today it only has an effect if the first argument to getaddrinfo
> > > is NULL. The intension (IIUC) is that it should be used when you plan to
> > > feed the result to bind (opposed to connect).
> > 
> > What do you mean by "Today"?  Both SuSv4 and the Linux man page are
> > unequivocal about the _only_ use of that flag being to special case
> > a NULL address (meaning 'this machine') to return either the wildcard
> > address or the LOOPBACK address.
> 
> I had in mind that at some point in the future (say with ipv8 or
> 802.11t-2042) the flag might mean more.

 ...

That would seem to be a pretty good summation of how we're failing to
converge here ...

Brainstorming imaginary problems to fit your proposed solution, especially
when you don't clearly say exactly what *your real* use case was here,
doesn't make that solution more compelling or less ill-advised.

If your real problem (aside from the NM bug which is now being tracked
here: https://bugs.debian.org/854078) is that you don't want to bind to
a specific address, just anything that appears at any time, then there
is no bug effecting you, you can already configure tftpd that way.

If it's instead that you do want to configure it to only use a subset of
the available addresses, and some of those addresses might genuinely be
hotplugged, long after boot, independent of the NM bug - then there's a
well known, long established, solution to that too.  Which I've mentioned
several times now.  Whatever brings those interfaces up needs a hook to
restart the services that you want bound to them, for each of the
services that doesn't do that itself by monitoring netlink events.

It's the "one simple trick" that solves all the problems you've expounded
here, also solves the problem you admit that your patch doesn't address,
and doesn't have the unfortunate side effects your patch does.

If:

> I'm only saying "don't refuse to work as good as you can".

Then why would you insist this crazy patch, which just crudely kludges
over a limited subset of the issues with hotplugged interfaces, leaving
others still broken - is better than one well-trodden solution which
fits all cases?


I don't use NM, so if someone who does wants us to add such a hook for
it to this package, they'll need to send a tested patch to do that.
I'll happily include it (and then close this clone of the bug) if they
do.  Bonus points if you also send one for ifupdown, but so far nobody
has reported wanting to use this with it and genuinely hotplugged
interfaces.

Please, let's focus on good solutions to the real problems rather than
straining to find good problems to fit a partial kludge.  This bug log
is already a maze of twisty little misconceptions - and the aim is to
dig our way *out* of that, not to find new ratholes to get lost in.


What doesn't work if the bug in NM is fixed, and it has a hook to
notify this service of real dynamic interface changes when they occur?

  Ron