ProxyDHCP replies on invalid range

Bug #1651044 reported by Alkis Georgopoulos
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
dnsmasq (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

In Ubuntu 16.04, I've configured dnsmasq to reply on subnet=10.160.37.0/24, yet it replies even when it gets an IP on subnet=10.161.254.0/24.
I've only seen this after clean system restart. If I restart dnsmasq later on, it works as expected.
Maybe when dnsmasq starts, the network isn't up yet, and it incorrectly initializes some networking information? I'm using network-manager with DHCP.

Details:
$ egrep -rv '^#|^$' /etc/dnsmasq.*
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=10.160.37.0,proxy
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=192.168.67.20,192.168.67.250,8h
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:enable-tftp
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:tftp-root=/var/lib/tftpboot/
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=17,/opt/ltsp/i386
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=etherboot,Etherboot
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=pxe,PXEClient
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=ltsp,"Linux ipconfig"
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:pxe,/ltsp/i386/pxelinux.0
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:etherboot,/ltsp/i386/nbi.img
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:ltsp,/ltsp/i386/lts.conf
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=vendor:pxe,6,2b
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-no-override
/etc/dnsmasq.d/ltsp-server-dnsmasq.conf:pxe-service=X86PC, "Boot from network", /ltsp/i386/pxelinux

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d0:50:99:a6:bc:0a brd ff:ff:ff:ff:ff:ff
    inet 10.161.254.185/24 brd 10.161.254.255 scope global dynamic enp2s0
       valid_lft 431873sec preferred_lft 431873sec
    inet6 fe80::f363:c1e2:9cb8:d9e2/64 scope link
       valid_lft forever preferred_lft forever

$ sudo netstat -nap | grep dnsmasq
[sudo] password for administrator:
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 843/dnsmasq
tcp6 0 0 :::53 :::* LISTEN 843/dnsmasq
udp 0 0 0.0.0.0:53 0.0.0.0:* 843/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:* 843/dnsmasq
udp 0 0 0.0.0.0:69 0.0.0.0:* 843/dnsmasq
udp 0 0 0.0.0.0:4011 0.0.0.0:* 843/dnsmasq
udp6 0 0 :::53 :::* 843/dnsmasq
udp6 0 0 :::69 :::* 843/dnsmasq
unix 2 [ ] DGRAM 15746 843/dnsmasq

$ grep dnsmasq /var/log/syslog | tail -n 30
Dec 19 10:52:17 ltsp-server systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server...
Dec 19 10:52:17 ltsp-server dnsmasq[630]: dnsmasq: syntax check OK.
Dec 19 10:52:20 ltsp-server dnsmasq[843]: started, version 2.75 cachesize 150
Dec 19 10:52:20 ltsp-server dnsmasq[843]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify
Dec 19 10:52:20 ltsp-server dnsmasq[843]: DNS service limited to local subnets
Dec 19 10:52:20 ltsp-server dnsmasq-dhcp[843]: DHCP, IP range 192.168.67.20 -- 192.168.67.250, lease time 8h
Dec 19 10:52:20 ltsp-server dnsmasq-dhcp[843]: DHCP, proxy on subnet 10.160.37.0
Dec 19 10:52:20 ltsp-server dnsmasq-tftp[843]: TFTP root is /var/lib/tftpboot/
Dec 19 10:52:20 ltsp-server dnsmasq[843]: no servers found in /var/run/dnsmasq/resolv.conf, will retry
Dec 19 10:52:20 ltsp-server dnsmasq[843]: read /etc/hosts - 7 addresses
Dec 19 10:52:23 ltsp-server systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.
Dec 19 10:52:29 ltsp-server dnsmasq[843]: reading /var/run/dnsmasq/resolv.conf
Dec 19 10:52:29 ltsp-server dnsmasq[843]: ignoring nameserver 127.0.0.1 - local interface
Dec 19 10:52:29 ltsp-server dnsmasq[843]: using nameserver 194.63.238.4#53
Dec 19 10:52:29 ltsp-server dnsmasq[843]: using nameserver 8.8.8.8#53
Dec 19 08:52:47 ltsp-server dnsmasq-dhcp[843]: PXE(enp2s0) 52:54:00:8f:74:ad proxy
Dec 19 08:52:47 ltsp-server dnsmasq-dhcp[843]: PXE(enp2s0) 10.161.254.195 52:54:00:8f:74:ad /ltsp/i386/pxelinux.0
Dec 19 08:52:47 ltsp-server dnsmasq-tftp[843]: sent /var/lib/tftpboot/ltsp/i386/pxelinux.0 to 10.161.254.195
...

Note that it replies in "52:54:00:8f:74:ad proxy" while it shouldn't.
If I run this:
# service dnsmasq restart

Then it behaves correctly:
Dec 19 09:01:17 ltsp-server dnsmasq-dhcp[2381]: no address range available for DHCP request via enp2s0

Revision history for this message
Alkis Georgopoulos (alkisg) wrote :

I did another test:
 * I unplugged the network cable so that the ltsp-server didn't have an ip.
 * I ran `service dnsmasq restart`.
 * I plugged the network cable back in.
 * ...and the problem came back again, i.e. dnsmasq replied on invalid range.

This again suggests that it's some kind of wrong initialization when the network is down while dnsmasq starts.

Using dnsmasq 2.75-1ubuntu0.16.04.1 on i386 architecture.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Alkis,
thank you for your report and your help to make Ubuntu better.
I like your preanalysis and agree to your assumption of some sort of bad initialization.

This bug is present in Debian too, and Ubuntu currently doesn't make any changes over the Debian package. So this bug would be best fixed directly in Debian, and then Ubuntu will pick up the fix automatically.
The only delta you see in Xenial is a security fix, so not a lot of "Ubuntu special" that could break it.

Also the versions are pretty much up to date - 2.76 as in Yakkety is the latest upstream.
I checked the changelog but there is no mentioning of the issue you are facing, yet if easily possible for you it might be worth checking the same on Yakkety or even Zesty.

I almost assume that it might be an upstream issue with dnsmasq itself, but in that case as well Debian should be notified to be able to pick it up as well.
You clearly have the best setup to reproduce if any more questions come in, therefore would you mind filing a bug with Debian and/or upstream and link it here please?

tags: added: needs-upstream-report
Changed in dnsmasq (Ubuntu):
importance: Undecided → High
Revision history for this message
Alkis Georgopoulos (alkisg) wrote :

Hi Christian,

Simon, the dnsmasq developer and Debian maintainer, frequently answers here in launchpad as well (and there's no upstream bug tracker).
In any case, I did forward the report to the dnsmasq mailing list:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q4/011010.html

Thank you for your feedback!

Revision history for this message
Paride Legovini (paride) wrote :

Hi,

I had a look at [1] and AIUI this wasn't recognized as an upstream bug. I also can't find a relevant Debian bug about this issue. The bug description says it affected Xenial, which is now in Extended Security Maintenance, so it's a Won't Fix there.

For >= Bionic we need confirmation from an affected user the bug is still present and valid. Waiting for feedback I'm marking this bug report as Incomplete.

[1] https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q4/011010.html

Changed in dnsmasq (Ubuntu):
status: New → Incomplete
importance: High → Undecided
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for dnsmasq (Ubuntu) because there has been no activity for 60 days.]

Changed in dnsmasq (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.