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?

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

Dnsmasq-discuss mailing list

Reply via email to