[It seems that I forgot to subscribe to this bug so I didn't see that there had been activity since the original exchange.]
In Message #75 2015-05-22 13:35 GMT+02:00 Ron <[email protected]> wrote: > It's not only tftp-hpa that would get burned by this. Any network > using service that needs to resolve or use an address would fail in > exactly the same way if started before your network is up. And lots > of them do. This isn't a new problem, you're just lucky that it's > the only thing that you are seeing it on. I don't believe that it's sensible for tftpd to assume that all network interfaces are up before it is started. We no longer live in a world of fixed network configurations. I believe that leaves daemons such as tftpd with three choices: 1. Bind to INADDR_ANY and accept connections on any network interfaces as they appear. Rely on firewalling to avoid unwanted connections. 2. Bind to network devices rather than addresses using SO_BINDTODEVICE. This isn't ideal since network devices may have multiple addresses. 3. Monitor network interfaces via netlink and bind to them as they appear. I believe that all but the first of these requires non-trivial development work. The current tftpd-hpa package defaults to being available on all interfaces via an IPv4 address. In Message #25, Ron rightly questioned whether this is still a sensible default. But, as I said in Message #30, I don't believe that changing the default to TFTP_ADDRESS=":69" makes the situation any worse, and it does mean that tftpd does work correctly when no network interface is available at startup. Maybe if the default was changed then it could be turned into a debconf question? Mike.
