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?
The text was updated successfully, but these errors were encountered:
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.