[FS#4189] DHCP server detection in dnsmasq init script is unreliable

[OpenWrt Bugs]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

A new Flyspray task has been opened.  Details are below. 

User who did this - Peter van Dijk (Habbie) 

Attached to Project - OpenWrt/LEDE Project
Summary - DHCP server detection in dnsmasq init script is unreliable
Task Type - Bug Report
Category - Base system
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Medium
Priority - Very Low
Reported Version - All
Due in Version - Undecided
Due Date - Undecided
Details - 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?

More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=4189

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.