[Dnsmasq-discuss] OpenWrt - dnsmasq - debugging delayed responses

Arseny Vakhrushev neoxic at icloud.com
Mon Jul 20 06:48:44 BST 2020


> On Jul 16, 2020, at 05:53, Daryl Richards <daryl at isletech.net <mailto:daryl at isletech.net>> wrote:
> 
> On 2020-07-15 9:13 p.m., Arseny Vakhrushev wrote:
>> Hello all,
>> I'm trying to debug delayed DHCP responses in OpenWrt 19.07.3. The machine is connected to the router via Ethernet to eliminate possible network latency and packet loss.
>> I tried playing with the debugging options of dnsmasq as well as with all the DHCP related options including dhcp-reply-delay with no apparent success.
> 
> You might have tried this, but you didn't explicitly mention it:
> 
> -5, --no-ping
>    (IPv4 only) By default, the DHCP server will attempt to ensure that an address is not in use before allocating it to a host. It does this by sending an ICMP echo request (aka "ping") to the address in question. If it gets a reply, then the address must already be in use, and another is tried. This flag disables this check. Use with caution.


Oh, boy.... Sure thing, I missed that one.:-) I assumed all DHCP related options are prefixed with "--dhcp-".

Yes, that was it! Thanks guys for your help.

I'm still a bit confused though why "--no-ping" is ON by default, especially when "--dhcp-sequential-ip" is NOT. Is it some sort of protection against manually assigned IP addresses that can conflict with a dedicated dynamic range?

* If yes, it doesn't look reliable because 50% of hosts/devices might be turned off, and 50% of those that are working might ignore ICMP ping requests. Doesn't look worthy being enabled by default.
* If no, then it must be some kind of a self check. In this case, it certainly should not be enabled by default at least with "--dhcp-sequential-ip" because the whole purpose of issuing addresses based on a MAC address hash is to avoid conflicts (along with having those addresses quasi permanent of course).

Even when this mechanism is on, it could be much better to commence a ping test on the background, i.e. after a DHCPOFFER has been sent, not before. This can avoid the largely unnecessary delay and hence further unnecessary duplicate DHCPDISCOVER requests by the client. In an unlikely event of IP address collision, the server simply refuses to commit the transaction by sending DHCPNAK instead of DHCPACK. It's also worth noting that there's already a room for such a background test because an average client collects DHCPOFFERs for some time (usually a second or more) and only then sends a DHCPREQUEST.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20200719/ec943031/attachment.html>


More information about the Dnsmasq-discuss mailing list