Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#4189 - DHCP server detection in dnsmasq init script is unreliable #9169

Open
openwrt-bot opened this issue Dec 17, 2021 · 1 comment
Open

FS#4189 - DHCP server detection in dnsmasq init script is unreliable #9169

openwrt-bot opened this issue Dec 17, 2021 · 1 comment
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Dec 17, 2021

Habbie:

Supply the following if possible:

  • Device problem occurs on: various
  • Software versions of OpenWrt/LEDE release, packages, etc.: various

============ Context

dnsmasq.init, as shipped in OpenWrt (any version I can find including master), tries to detect active DHCP servers on the network before configuring dnsmasq as a DHCP server.

============ Short

The 3 second udhcpc timeout in dnsmasq.init is too short and is likely to not notice another dnsmasq running on the same LAN.

============ Long
This happens with the following line in dnsmasq.init:

    udhcpc -n -q -s /bin/true -t 1 -i "$ifname" >&- && rv=1 || rv=0

with these options, udhcpc gives up after 3 seconds if no response is received.

However, dnsmasq, with default settings (not passing --5/--no-ping), will ICMP ping probe an address before it hands it out. The timeout for that is "two to three seconds" - see "Q: Does the dnsmasq DHCP server probe addresses before allocating them, as recommended in RFC2131?" at https://thekelleys.org.uk/dnsmasq/docs/FAQ . This text also mentions that dnsmasq can only probe one address at a time, and thus only handle one DHCP request at a time. This means that it is very easy for the udhcpc call to falsely timeout because dnsmasq was not responding, or not responding quickly enough.

I noticed this in practice on a network with two dnsmasqs already running. The third one would randomly end up with DHCP enabled or disabled, depending on whether udhcpc timed out, or got a lease in just under 3 seconds.

============ What to do

Increase the udhcpc timeout?

Remove the whole check, as it is unreliable, and thus might surprise a user two weeks from now?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Dec 17, 2021

paulfertser:

Another idea to consider would be using DHCPINFORM packet instead, like dhcping -i does: https://salsa.debian.org/debian/dhcping/-/blob/debian/master/dhcping.c . However, it mentions that "DHCPINFORM packets can only be used on subnets the server is authoritative for. If the monitoring script runs on a subnet the server isn't authoritative for, it should use the DHCPREQUEST packets." I'd still prefer fast DHCPINFORM test to not having any test at all, and it should cover the majority of usecases reliably I guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant