[ipxe-devel] DHCP timeouts

Alex Williamson alex.williamson at redhat.com
Wed Jun 5 19:26:58 UTC 2013


Looking through the code and the RFCs and specs, I'm having trouble
understanding why iPXE does what it does for DHCP/PXE timeouts.  As I
understand it, the code will currently re-transmit discovery packets
with delays of 1,2,4,8 seconds.  This gives a timeout after a total of
15 seconds.  However RFC2131 indicates the initial retry should be after
4 seconds with exponential backoff up to a maximum of 64 seconds.  Thus
we should use retry delays of 4,8,16,32,64 seconds.  It's a little
ambiguous whether we send that last packet, so this could also be
interpreted as 4,8,16,32 for a total of 60 seconds.  This is actually
how the PXE specification defines it.

So, the first question is why do we take such an abbreviated approach?
Is there a spec that supports it?

Re-transmission of the request response is a little more difficult.
RFC2131 suggests using the same backoff algorithm as above, with a 60s
total timeout.  The PXE spec indicates re-transmission timeouts of
1,2,3,4 seconds.  iPXE retries with delays of 0.25,0.5,1,2,4,8 seconds.

Next, when sending option 60, the PXE spec defines that the client
should wait through the 4 and 8 second timeouts for a response that
includes the PXEClient tag.  iPXE waits for 2 seconds total to have
elapsed.  Why?  Are we just trying to reduce that 12 second delay in a
non-PXE environment?

If there's agreement that at least the discovery phase should be
something closer to the spec defined intervals, I can post a patch.


More information about the ipxe-devel mailing list