[Dnsmasq-discuss] [RFC] Add --dhcp-reply-delay option to delay DHCP replies

[Floris Bos]

Hi,

On 03/22/2017 10:01 PM, Simon Kelley wrote:
> As a patch, it looks pretty good.
>
> The main problem I have is that the new option becomes one of the those
> annoying things that have to be set to make things work, but have no
> other value. There are already quite a few dnsmasq options which are
> essentially "--dont-break" and if I can avoid another, I will.
>
> You say that the PXE bug is "if it receives a (proxy) DHCP
> reply instantly", is this really only with proxy DHCP?

It happens in all instances in which the packet that has the pxe/tftp 
boot information is send without any delay.
In non-proxy mode it also happens when the ping check is skipped.

>   That's
> believable: a PXE implementation which gets the proxy reply _before_ the
> standard DHCP reply might well get confused and, let's face it, it
> doesn't take much to confuse most PXE clients :-(
>
> If that's the case, would it be enough to delay replies by a fixed time
> always and only if they're proxy replies? That would have the effect of
> making things just work, with needing a "--dont-break" option, and
> wouldn't affect the normal use-case at all.
>
> It's a bit more difficult to implement, but not impossible. worst case,
> dhcp_reply() needs to return a flag indicating that PXE-proxy reply was
> made, and the call to the delay routine made based on that.

In this particular case, it is likely that only one vendor is affected.
I can probably activate the workaround automatically based on MAC OUI, 
if you prefer not to have additional options.

> Only other quibble is the duplication of all the poll-loop code into
> dhcp_delay(). Would it be neater to make one routine handle waiting for
> an icmp-ping reply and just waiting?

That's possible.
Do would make the function's signature a bit cryptic though, along the 
lines of:

int delay_dhcp(time_t start, int sec, int fd, struct in_addr addr, int id);




Yours sincerely,

Floris Bos