I don't know how my case enters this discussion, but it is certainly connected to the current default installation wherein network-manager starts an instance of dnsmasq to act as a DHCP, DNS and TFTP server.
I was troubleshooting an LTSP-PNP client boot problem under Lubuntu Quantal. I installed with a single NIC per https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp. 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. I can also run this on the server itself to get a similar failure: $ cd /tmp $ tftp 192.168.1.102 -v -m binary -c get /ltsp/i386/pxelinux.0 mode set to octet Connected to 192.168.1.102 (192.168.1.102), port 69 getting from 192.168.1.102:/var/lib/tftpboot/ltsp/i386/pxelinux.0 to pxelinux.0 [octet] Transfer timed out. A CRITICAL NOTE: This is using the default network-manager configuration of the network interface (using the default DHCP configuration, and the connection is "Available to all users"). If I merely configure the network interface (again for DHCP) via /etc/network/interfaces, the TFTP error disappears and the LTSP client boots. But it introduces a new problem on both server and client: DNS resolution fails. I can fix the DNS resolution problem by creating /etc/resolvconf/resolv.conf.d/tail with contents: nameserver (my nameserver 1) nameserver (my nameserver 2) But trying to identify and perhaps work around the problem with network- manager and dnsmasq, I undid the changes to /etc/network/interfaces and deleted /etc/resolvconf/resolv.conf.d/tail. It turns out that if I merely $ sudo service dnsmasq restart then the LTSP client will boot normally. Hunting for some diagnostic information, I ran this command before and after restarting dnsmasq: $ sudo netstat -nap | grep dnsmasq Relevant output before restarting: udp 0 0 127.0.0.1:69 0.0.0.0:* 887/dnsmasq After restarting: udp 0 0 127.0.0.1:69 0.0.0.0:* 1967/dnsmasq udp 0 0 192.168.1.102:69 0.0.0.0:* 1967/dnsmasq (where 192.168.1.102 is the server IP) 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. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting Status in “djbdns” package in Ubuntu: Confirmed Status in “dnsmasq” package in Ubuntu: Fix Released Status in “network-manager” package in Ubuntu: Fix Released Status in “pdns-recursor” package in Ubuntu: Invalid Status in “pdnsd” package in Ubuntu: Invalid Status in “djbdns” source package in Precise: Confirmed Status in “dnsmasq” source package in Precise: Triaged Status in “network-manager” source package in Precise: Triaged Status in “pdns-recursor” source package in Precise: Invalid Status in “pdnsd” source package in Precise: Invalid Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out "#dns=dnsmasq" in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
