[Dnsmasq-discuss] [RFC] Add --dhcp-reply-delay option to delay DHCP replies
bos at je-eigen-domein.nl
Thu Mar 23 00:49:59 GMT 2017
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.
> 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?
Do would make the function's signature a bit cryptic though, along the
int delay_dhcp(time_t start, int sec, int fd, struct in_addr addr, int id);
More information about the Dnsmasq-discuss