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

Petr Menšík pemensik at redhat.com
Mon Jul 20 11:07:16 BST 2020



On 7/20/20 7:48 AM, Arseny Vakhrushev wrote:
>> 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?
It might protect against collisions with other DHCP servers as well. I
think no-ping is not a good default, ping should be safe to use.
> 
> * 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).
That would work well only if you protect the network against any other
dhcp server. Only expensive switches can do that.
> 
> 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.

No, ping should be sent before DHCPOFFER. It should not offer address
already in use. But maybe it should use short timeout for DHCPOFFER. If
no response arrives in short time, assume it can proceed. Still watch
for response until DHCPACK or DHCPNACK is sent. Waiting 2 seconds before
Offer is sent is way too much. It might be okay to wait for 600ms, then
send an offer. But send DHCPACK after timeout over 1 second might be
okay. Though it would complicate the logic of ping.

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB




More information about the Dnsmasq-discuss mailing list