Comment 120 for bug 959037

> the current default installation wherein network-manager starts
> an instance of dnsmasq to act as a DHCP, DNS and TFTP server.

NetworkManager starts an instance of dnsmasq to act only as a non-caching DNS nameserver forwarder. This instance listens only on the loopback interface 127.0.1.1.

If your client is DHCPing with a dnsmasq instance on an Ubuntu server then that dnsmasq instance is most probably a "standalone" instance, configured by means of files included in the "dnsmasq" package (not to be confused with the "dnsmasq-base" package which contains little more than the dnsmasq binary and which both the dnsmasq package and the network-manager package depend on) and started by an initscript, not by NetworkManager.

In reading further into your text my understanding is hampered by the fact that I am not entirely sure which machine you are referring to at different points in your text.

> The problem is that the LTSP client, after successfully getting
> DHCP assignments, fails to download the pxelinux boot image.
> It reports "PXE-E32: TFTP open timeout."
> To be more specific on the DHCP assignments, it identifies
> my hardware router as the DHCP server and the default gateway.
> It identifies the LTSP server as proxy and boot server.

Is your LTSP server running Ubuntu and standalone dnsmasq? Then shouldn't the client use your LTSP server as the DHCP server?

> So dnsmasq is not binding to my server IP during boot.
> If I remove /etc/dnsmasq.d/network-manager
> (which issues the sole dnsmasq directive to bind all the
> interfaces instead of listening on 0.0.0.0) and restart the
> server it allows the client to boot normally.

I think I know what is happening. The network-manager package causes (by means of the /etc/dnsmasq.d/network-manager file) the standalone dnsmasq to start in "bind-interfaces" mode. In that mode dnsmasq doesn't listen on the wildcard IP address; it only listens on the addresses assigned to interfaces that are up when it (dnsmasq) starts. At boot, dnsmasq starts before the external interface is configured via DHCP, so dnsmasq doesn't listen on the external interface. If dnsmasq is restarted after the external interface is configured then dnsmasq listens on that interface too.

If you remove /etc/dnsmasq.d/network-manager then standalone dnsmasq listens on the wildcard address when it starts and all is well except that now standalone dnsmasq conflicts with the NetworkManager-controlled dnsmasq instance. To fix this you have to disable the latter. Edit /etc/NetworkManager/NetworkManager.conf and comment out the line "dns=dnsmasq": put a '#' at the beginning of the line.

In the future we hope that standalone dnsmasq running in bind-interfaces mode will be enhanced such that it listens on interfaces that are brought up after it (dnsmasq) starts. The author of dnsmasq, Simon Kelley, has already implemented this enhancement experimentally. Once that work is done it will be possible to run dnsmasq in bind-interfaces mode without causing the problem that you ran into.