Hi, 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. Thanks, Alex _______________________________________________ ipxe-devel mailing list [email protected] https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
