[I realize this is code from 15 years ago so i am not sure if anyone still knows or remembers the answer] sys/nfs/bootp_subr.c is used to request via bootp or dhcp an address and a boot path. The negotiation is done in a loop, and apparently when replies are received on _all_ interfaces, the code extends the loop by another 3 seconds (BOOTP_SETTLE_DELAY) with a logic that is not documented and I do not follow. Any idea ? I would understand not stopping at the first reply in case we want to pick the 'best' one from multiple responses (which is implemented, to some degree, in bootpc_received() ). But if that is the case, one should either 1) use an unconditionally large timeout, or 2) take the first incoming packet (not necessarily valid) on _any_ interface as a signal that "ok this interface is now on" and apply the grace period from there. Why do i care ? I am booting a diskless kernel with bhyve and BOOTP_SETTLE_DELAY unnecessarily extends the boot time a lot, and even worse delays happen if you have multiple interfaces that do not respond due to some other unclear logic. Depending on what is the original intention i would like to implement either option #1 or #2 above. Also, I would like to use environment variables to set/override the in-kernel bootp settings cheers luigiReceived on Sun Jan 04 2015 - 20:04:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:54 UTC