dnsmasq started before all interfaces are up

[Thomas Schweikle]

dnsmasq is started as soon a s network set up lo. since all other interfaces are not up at that point in time, dnsmasq does not know anythinmg about these interfaces. If your network is a bit more complex you will have to restart dnsmasq manualy after all interfaces are up.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: dnsmasq 2.57-1ubuntu1
Uname: Linux 3.0.4 x86_64
NonfreeKernelModules: openafs
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
Date: Mon Oct 17 14:25:15 2011
PackageArchitecture: all
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: dnsmasq
UpgradeStatus: Upgraded to oneiric on 2011-10-17 (0 days ago)
modified.conffile..etc.resolvconf.update.d.dnsmasq: [deleted]
mtime.conffile..etc.default.dnsmasq: 2011-05-10T10:34:45.538035
mtime.conffile..etc.dnsmasq.conf: 2011-09-27T19:17:49.862539

[Clint Byrum (clint-fewbar)]

Thomas, runlevel 2 is not entered until after all interfaces listed as 'auto' in /etc/network/interfaces are up, as of Ubuntu 11.10. Since dnsmasq starts in runlevel 2, it should not have any chance to start before that network configuration is applied.

Can you send an ls -l /etc/rcS.d and /etc/rc2.d along with your /etc/network/interfaces file and ls -l /run/network ?

THANKS!

marking incomplete.

[Thomas Schweikle (tps)]

Yes, that's right, but there are interfaces not started from /etc/network/interfaces or Network Manager:
* VMware Workstation / Player installs interfaces starting VMware daemons
* VirtualBox installs interfaces
* KVM may install an additional bridge
* some VPN software installs tun/tap interfaces or virtual interfaces up on an existing interface

As far as I could find:
* VMware is started after dnsmasq, leading to a situation dhcp via dnsmasq works, but DNS doesn't
* VirtualBox creates interfaces and bridges on the fly --- sometimes dhcp works, sometimes it doesn't; DNS did not work always
* KVM interfaces are started concurently with dnsmasq, because kvm is started after "network" is up. Sometimes you'll get full functionality, sometimes you do not. If KVM starts its own dnsmasq both daemons challenge with each other about whom answers dhcp --- sometimes the VM is assigned the one address, sometimes the other. DNS may work or may not.
* VPN: sometimes dnsmasq binds dhcp to VPN, sometimes it doesn't. Either way: it leads into trouble.

To make dnsmasq work with dhcp, dns (and, if configured tftp) you'll have to restart the daemon each time a new interface it shall bind to is started.

[Thomas Schweikle (tps)]

tps@ivory:~$ ls -l /etc/rcS.d
total 4
-rw-r--r-- 1 root root 447 Jul 14 07:11 README
lrwxrwxrwx 1 root root 18 Oct 20 00:23 S01apparmor -> ../init.d/apparmor
lrwxrwxrwx 1 root root 16 Oct 20 00:23 S01brltty -> ../init.d/brltty
lrwxrwxrwx 1 root root 23 Nov 27 21:21 S01etc-setserial -> ../init.d/etc-setserial
lrwxrwxrwx 1 root root 20 Nov 27 21:21 S01lm-sensors -> ../init.d/lm-sensors
lrwxrwxrwx 1 root root 15 Oct 20 00:23 S01quota -> ../init.d/quota
lrwxrwxrwx 1 root root 16 Nov 27 21:21 S01setkey -> ../init.d/setkey
lrwxrwxrwx 1 root root 19 Nov 27 21:21 S01setserial -> ../init.d/setserial
lrwxrwxrwx 1 root root 20 Oct 20 00:23 S01x11-common -> ../init.d/x11-common
lrwxrwxrwx 1 root root 21 Oct 20 00:23 S02pcmciautils -> ../init.d/pcmciautils
lrwxrwxrwx 1 root root 17 Nov 27 21:21 S04urandom -> ../init.d/urandom

tps@ivory:~$ ls -l /etc/rc2.d
total 4
lrwxrwxrwx 1 root root 32 Nov 27 21:23 K08vmware-USBArbitrator -> /etc/init.d/vmware-USBArbitrator
-rw-r--r-- 1 root root 677 Jul 14 07:11 README
lrwxrwxrwx 1 root root 17 Nov 27 21:21 S01openvpn -> ../init.d/openvpn
lrwxrwxrwx 1 root root 19 Nov 27 21:21 S02bacula-fd -> ../init.d/bacula-fd
lrwxrwxrwx 1 root root 19 Nov 27 21:21 S02bluetooth -> ../init.d/bluetooth
lrwxrwxrwx 1 root root 17 Nov 27 21:21 S02dnsmasq -> ../init.d/dnsmasq
lrwxrwxrwx 1 root root 13 Nov 27 21:21 S02gpm -> ../init.d/gpm
lrwxrwxrwx 1 root root 17 Nov 27 21:21 S02hddtemp -> ../init.d/hddtemp
lrwxrwxrwx 1 root root 21 Nov 27 21:21 S02libnss-ldap -> ../init.d/libnss-ldap
lrwxrwxrwx 1 root root 14 Nov 27 21:21 S02lirc -> ../init.d/lirc
lrwxrwxrwx 1 root root 21 Nov 27 21:21 S02loadcpufreq -> ../init.d/loadcpufreq
lrwxrwxrwx 1 root root 14 Nov 27 21:21 S02nscd -> ../init.d/nscd
lrwxrwxrwx 1 root root 22 Nov 27 21:21 S02opencryptoki -> ../init.d/opencryptoki
lrwxrwxrwx 1 root root 20 Nov 27 21:21 S02postgresql -> ../init.d/postgresql
lrwxrwxrwx 1 root root 18 Nov 27 21:21 S02pppd-dns -> ../init.d/pppd-dns
lrwxrwxrwx 1 root root 20 Nov 27 21:21 S02pulseaudio -> ../init.d/pulseaudio
lrwxrwxrwx 1 root root 18 Nov 27 21:21 S02quotarpc -> ../init.d/quotarpc
lrwxrwxrwx 1 root root 15 Nov 27 21:21 S02saned -> ../init.d/saned
lrwxrwxrwx 1 root root 27 Nov 27 21:21 S02speech-dispatcher -> ../init.d/speech-dispatcher
lrwxrwxrwx 1 root root 14 Nov 27 21:21 S02sudo -> ../init.d/sudo
lrwxrwxrwx 1 root root 23 Nov 27 21:21 S02uml-utilities -> ../init.d/uml-utilities
lrwxrwxrwx 1 root root 29 Nov 27 21:21 S02unattended-upgrades -> ../init.d/unattended-upgrades
lrwxrwxrwx 1 root root 20 Nov 27 21:21 S02virtualbox -> ../init.d/virtualbox
lrwxrwxrwx 1 root root 17 Nov 27 21:21 S02winbind -> ../init.d/winbind
lrwxrwxrwx 1 root root 13 Nov 27 21:21 S02xfs -> ../init.d/xfs
lrwxrwxrwx 1 root root 22 Nov 27 21:21 S03acpi-support -> ../init.d/acpi-support
lrwxrwxrwx 1 root root 22 Nov 27 21:21 S03cpufrequtils -> ../init.d/cpufrequtils
lrwxrwxrwx 1 root root 19 Nov 27 21:21 S03dns-clean -> ../init.d/dns-clean
lrwxrwxrwx 1 root root 20 Nov 27 21:21 S03kerneloops -> ../init.d/kerneloops
lrwxrwxrwx 1 root root 27 Nov 27 21:21 S03nfs-kernel-server -> ../init.d/nfs-kernel-server
lrwxrwxrwx 1 root root 15 Nov 27 21:2...

[Simon Kelley (simon-thekelleys)]

On 08/12/11 12:57, Thomas Schweikle wrote:
> Yes, that's right, but there are interfaces not started from /etc/network/interfaces or Network Manager:
> * VMware Workstation / Player installs interfaces starting VMware daemons
> * VirtualBox installs interfaces
> * KVM may install an additional bridge
> * some VPN software installs tun/tap interfaces or virtual interfaces up on an existing interface
>
> As far as I could find:
> * VMware is started after dnsmasq, leading to a situation dhcp via dnsmasq works, but DNS doesn't
> * VirtualBox creates interfaces and bridges on the fly --- sometimes dhcp works, sometimes it doesn't; DNS did not work always
> * KVM interfaces are started concurently with dnsmasq, because kvm is started after "network" is up. Sometimes you'll get full functionality, sometimes you do not. If KVM starts its own dnsmasq both daemons challenge with each other about whom answers dhcp --- sometimes the VM is assigned the one address, sometimes the other. DNS may work or may not.
> * VPN: sometimes dnsmasq binds dhcp to VPN, sometimes it doesn't. Either way: it leads into trouble.
>
> To make dnsmasq work with dhcp, dns (and, if configured tftp) you'll
> have to restart the daemon each time a new interface it shall bind to is
> started.
>

Dnsmasq will cope fine with dynamically-created interfaces, as long as
"bind-interfaces" is NOT set in the configuration.

Simon.

[Clint Byrum (clint-fewbar)]

Thomas, i'd argue that any service not using ifup/ifdown, and not manually calling the /etc/network/if-up.d scripts after bringing interfaces up is the bug then. NetworkManager has a plugin specifically to do this, and vmware/virtualbox should too if they're going to manage interfaces. Of course, it also means that they need to start before runlevel 2, so they'll need upstart jobs.

Still, I don't think this is dnsmasq's problem. As Simon says, just make sure dnsmasq is not binding to specific interfaces.

[Thomas Schweikle (tps)]

Hmmmm. If this is the reason, how to force dnsmasq not to respond on some interfaces, while listening on all others, with different configurations per interface?

Wouldn't it be better to configure dnsmasq even for interfaces not there at startup, and if these interfaces come up take them, if configs match? Avoiding unconfigured interfaces?

[Simon Kelley (simon-thekelleys)]

On 20/12/11 20:55, Thomas Schweikle wrote:
> Hmmmm. If this is the reason, how to force dnsmasq not to respond on
> some interfaces, while listening on all others, with different
> configurations per interface?
>
> Wouldn't it be better to configure dnsmasq even for interfaces not there
> at startup, and if these interfaces come up take them, if configs match?
> Avoiding unconfigured interfaces?
>

That's exactly what happens without --bind-interface, interfaces which
are configured in dnsmasq but don't exist at startup generate a warning
only, and start to work when they are created.

Packets from interfaces which are not configured are ignored.

Simon.

[Thomas Schweikle (tps)]

> That's exactly what happens without --bind-interface, interfaces which
> are configured in dnsmasq but don't exist at startup generate a warning
> only, and start to work when they are created.

This seems to be correct.

> Packets from interfaces which are not configured are ignored.

This isn't correct at all. Assume configuration:

auto vm0
iface vm0 inet dhcp
  bridge_fd 3
  bridge_hello 2
  bridge_maxage 12
  bridge_stp off
  bridge_ports eth0

auto vm1
iface vm1 inet static
  address 172.18.1.1
  netmask 255.255.255.0
  bridge_fd 3
  bridge_hello 2
  bridge_maxage 12
  bridge_stp off
  pre-up brctl addbr $IFACE
  post-down brctl delbr $IFACE

auto vm8
iface vm1 inet static
  address 172.18.8.1
  netmask 255.255.255.0
  bridge_fd 3
  bridge_hello 2
  bridge_maxage 12
  bridge_stp off
  pre-up brctl addbr $IFACE
  post-down brctl delbr $IFACE

and in /etc/dnsmasq.conf:
localise-queries
domain-needed
expand-hosts
no-negcache
filterwin2k
cache-size=150

dhcp-authoritative
dhcp-fqdn
dhcp-leasefile=/var/lib/misc/dnsmasq.leases

dhcp-boot=boot/grub/i386-pc/core.0
dhcp-no-override
tftp-root=/srv/tftpboot
enable-tftp

listen-address=127.0.0.1
resolv-file=/etc/resolv.dhcp

domain=fritz.box

#== Interface vm1
listen-address=172.18.1.1
domain=fritz.box,172.18.1.0/24
dhcp-range=172-18-1,172.18.1.129,172.18.1.200,255.255.255.0,30m
dhcp-option=net:172-18-1,28,172.18.1.255 # option broadcast address
dhcp-option=net:172-18-1,3,172.18.1.1 # option default route
dhcp-option=net:172-18-1,option:domain-search,fritz.box # option domain search (RFC-3397)
dhcp-option=net:172-18-1,42,172.18.1.1 # option ntp-servers
dhcp-option=net:172-18-1,6,172.18.1.1 # option domain name servers
dhcp-option=net:172-18-1,15,fritz.box # option domain name
dhcp-option=net:172-18-1,40,fritz.box # option nis domain
dhcp-option=net:172-18-1,23,50 # option ttl
dhcp-option=net:172-18-1,19,0 # option ip-forwarding off
dhcp-option=net:172-18-1,44,0.0.0.0 # set netbios-over-TCP/IP nameserver(s) aka WINS server(s)
dhcp-option=net:172-18-1,45,0.0.0.0 # netbios datagram distribution server
dhcp-option=net:172-18-1,46,8 # netbios node type

dhcp-option=net:172-18-1,vendor:PXEClient,1,0.0.0.0
dhcp-option=net:172-18-1,vendor:MSFT,2,1i # Microsoft: tell client to release the lease

#== Interface vm8
listen-address=172.18.8.1
domain=fritz.box,172.18.8.0/24
dhcp-range=172-18-8,172.18.8.129,172.18.8.200,255.255.255.0,30m
dhcp-option=net:172-18-8,28,172.18.8.255 # option broadcast address
dhcp-option=net:172-18-8,3,172.18.8.1 # option default route
dhcp-option=net:172-18-8,option:domain-search,fritz.box # option domain search (RFC-3397)
dhcp-option=net:172-18-8,42,172.18.8.1 ...

[Thomas Schweikle (tps)]

Have to be a bit more precise: there is an additional interface not configured at all. This interface only receives and answers dhcp queries. The other interface, which is configured is OK.

The problem seems to be interfaces which are not configured and may be up sometimes. As soon as I configure this interface, all is OK again --- no more answered queries on this interface. But I have to configure it not to answer any dhcp-queries. If I leave it unconfigured this Interface will receive dhcp-queries and answer them.

The Interface in question is configured:
auto vm2
iface vm2 inet static
  address 192.168.116.1
  netmask 255.255.255.0
  bridge_fd 3
  bridge_hello 2
  bridge_maxage 12
  bridge_stp off
  bridge_ports eth1
  pre-up brctl addbr $IFACE
  post-down brctl delbr $IFACE

[Simon Kelley (simon-thekelleys)]

On 02/01/12 09:44, Thomas Schweikle wrote:
>> That's exactly what happens without --bind-interface, interfaces which
>> are configured in dnsmasq but don't exist at startup generate a warning
>> only, and start to work when they are created.
>
> This seems to be correct.
>
>> Packets from interfaces which are not configured are ignored.
>
> This isn't correct at all. Assume configuration:
>
> auto vm0
> iface vm0 inet dhcp
> bridge_fd 3
> bridge_hello 2
> bridge_maxage 12
> bridge_stp off
> bridge_ports eth0
>
> auto vm1
> iface vm1 inet static
> address 172.18.1.1
> netmask 255.255.255.0
> bridge_fd 3
> bridge_hello 2
> bridge_maxage 12
> bridge_stp off
> pre-up brctl addbr $IFACE
> post-down brctl delbr $IFACE
>
> auto vm8
> iface vm1 inet static
> address 172.18.8.1
> netmask 255.255.255.0
> bridge_fd 3
> bridge_hello 2
> bridge_maxage 12
> bridge_stp off
> pre-up brctl addbr $IFACE
> post-down brctl delbr $IFACE
>
> and in /etc/dnsmasq.conf:
> localise-queries
> domain-needed
> expand-hosts
> no-negcache
> filterwin2k
> cache-size=150
>
> dhcp-authoritative
> dhcp-fqdn
> dhcp-leasefile=/var/lib/misc/dnsmasq.leases
>
> dhcp-boot=boot/grub/i386-pc/core.0
> dhcp-no-override
> tftp-root=/srv/tftpboot
> enable-tftp
>
> listen-address=127.0.0.1
> resolv-file=/etc/resolv.dhcp
>
> domain=fritz.box
>
> #== Interface vm1
> listen-address=172.18.1.1
> domain=fritz.box,172.18.1.0/24
> dhcp-range=172-18-1,172.18.1.129,172.18.1.200,255.255.255.0,30m
> dhcp-option=net:172-18-1,28,172.18.1.255 # option broadcast address
> dhcp-option=net:172-18-1,3,172.18.1.1 # option default route
> dhcp-option=net:172-18-1,option:domain-search,fritz.box # option domain search (RFC-3397)
> dhcp-option=net:172-18-1,42,172.18.1.1 # option ntp-servers
> dhcp-option=net:172-18-1,6,172.18.1.1 # option domain name servers
> dhcp-option=net:172-18-1,15,fritz.box # option domain name
> dhcp-option=net:172-18-1,40,fritz.box # option nis domain
> dhcp-option=net:172-18-1,23,50 # option ttl
> dhcp-option=net:172-18-1,19,0 # option ip-forwarding off
> dhcp-option=net:172-18-1,44,0.0.0.0 # set netbios-over-TCP/IP nameserver(s) aka WINS server(s)
> dhcp-option=net:172-18-1,45,0.0.0.0 # netbios datagram distribution server
> dhcp-option=net:172-18-1,46,8 # netbios node type
>
> dhcp-option=net:172-18-1,vendor:PXEClient,1,0.0.0.0
> dhcp-option=net:172-18-1,vendor:MSFT,2,1i # Microsoft: tell client to release the lease
>
> #== Interface vm8
> listen-address=172.18.8.1
> domain=fritz.box,172.18.8.0/24
> dhcp-range=172-18-8,172.18.8.129,172.18.8.200,255.255.255.0,30m
> dhcp-option=net:172-18-8,28,172.18.8.255 # option broadcast address
> dhcp-option=net:172-18-8,3,172.18.8.1 ...

[Simon Kelley (simon-thekelleys)]

An addition to my last reply:

If a DHCP request is received via in interface which doesn't have an IP
address, there will be a log message, but the request will be otherwise
ignored.

Cheers,

Simon.

[Thomas Schweikle (tps)]

Thanks for the clarification here. I've tried now with --listen-interface and I am sure dnsmasq does what it is supposed to do --- only answer dhcp requests arriving on certain interfaces, but ignoring others!

In this case It was a missinterpretation of how the various interface related options work. Thanks again for clarification.

[Clint Byrum (clint-fewbar)]

Thomas, thanks for the updates. I think you have a pretty complicated setup, and we can't necessarily cater to such a setup in the packaging given the number of options dnsmasq has. There's a path for other users with a similar setup to yours, and that is --listen-interface.

Closing this as Invalid, but please feel free to re-open it if you feel there is more we can do in Ubuntu to address the issue.