Hello Simon, You know the 3 seconds wait for a pong (ping reply) during which dnsmasq remains deaf to other DHCP requests? according to your comments around the icmp_ping() function in dnsmasq.c it seems to be sort of "deliberate known problem" and considering that it can lead to denial of service I was wondering what the rationale has been behind your decision to leave dnsmasq deliberately deaf to DHCP during those 3 seconds.
In case you can't see how that can lead to DoS I'm going to describe the scenario: a malicious DHCP client could exploit that dnsmasq's behavior by just sending continuous (apparently legitimate) discovery requests which make dnsmasq always compute the same IP address for which, of course, no host responds to pings; this way the socket's receive buffer of UDP port 68 gets filled by those discovery requests because dnsmasq serves them at the slow rate of one every 3 seconds and when other legitimate requests arrive they just enter that very long queue and end up being served really too late, thus leading to the overall DoS. Actually there's not even need for a real flood of requests: all the malicious client needs to do to make that happen sooner or later is to send just one request every 1 or 2 seconds; this was my actual case due to a VoIP phone with buggy firmware which just ignores dnsmasq's offers and keeps sending discovery requests. Thank you, cheers, Luca