On Sat, Nov 29, 2014 at 08:32:05PM +0000, Mike Crowe wrote: > On Sunday 30 November 2014 at 06:40:26 +1030, Ron wrote: > > On Sat, Nov 29, 2014 at 07:14:16PM +0000, Mike Crowe wrote: > > > On Sunday 30 November 2014 at 05:25:10 +1030, Ron wrote: > > > > On Sat, Nov 29, 2014 at 04:09:09PM +0000, Mike Crowe wrote: > > > > > When a Wheezy or Jessie machine is fitted with an SSD the machine > > > > > often > > > > > boots so quickly that tftpd-hpa is started before the network is fully > > > > > configured. The problem is reproducible with sysvinit (on Wheezy) and > > > > > systemd (on Jessie) although it may be easier to reproduce with > > > > > systemd. > > > > > > > > What are you using to set up your network? > > > > > > It looks like it's currently NetworkManager on all the machines I've seen > > > this on. I thought I'd seen the problem with ifupdown too but no longer > > > have any evidence to support that. > > > > With ifupdown and allow-hotplug it's definitely possibly, since unlike > > auto, that doesn't wait for the defined network(s) to come up before > > the rest of the init scripts continue (and we've seen lots of services > > fail due to that). For NM, I'm less sure of what the mechanics might > > be, but I know who to talk to about that. > > If NM is connecting to WiFi or perhaps with stuff like 802.1x (not that I'm > using such things) then the network might not even come up until after > login. > > > > Of course on a laptop it is perfectly normal to not have any working > > > network interfaces at boot time so it seems rather unfair of tftpd-hpa not > > > to start when it is not configured to be bound to a specific interface. > > > > Are you really running this on a laptop, or is that just an example? > > I am. We use TFTP for booting embedded Linux devices during development. > > > It's also not quite clear to me yet exactly what the desirable default > > behaviour should be in such a case. Would you really want it to bind > > to any random wifi hotspot that NM on your laptop might find? > > > > That doesn't quite seem ideal either ... > > Indeed. But I'm not really making anything super-secret available via TFTP > and don't allow writing. Having said that, I don't think that > NetworkManager will randomly connect to networks it doesn't know about but > perhaps it could be fooled into doing so if the ESSID matches even if the > BSSID doesn't. :( > > But I don't think that the default of :69 is any worse than 0.0.0.0:69 > would be though - unless you have a deep distrust of anyone on IPv6. :)
Right, I'm not saying it's necessarily wrong for someone to configure it like this explicitly if they are sure it's ok for their use case, and the INADDR_ANY is almost surely just because this predates support for IPv6 and hadn't been looked at again since. And also surely, at least in part, because it also predates people using this on laptops in potentially hostile environments where network interfaces it might bind to can come and go with the wind ... Which just has me wondering more generally if either of these is still an appropriate *default*, and if not what might be more appropriate. I'm not sure we need to go full tin-foil here, but there seems to be at least a few things here that probably could do with a bit more thought. Another I don't have the answer to right now off the top of my head is, will this even listen on interfaces that come up after the daemon is started without us explicitly using IP_FREEBIND? Having it not fail at startup isn't a lot of help if it still won't actually communicate on those interfaces. That's easy enough to test, but I'm not remembering the answer to this being a definite "yes it will" ... Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
