Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 Jan 2015 22:09:19 +0100
From:      Luigi Rizzo <rizzo@iet.unipi.it>
To:        current@freebsd.org, net@freebsd.org, tegge@freebsd.org
Subject:   BOOTP_SETTLE_DELAY in sys/nfs/bootp_subr.c ?
Message-ID:  <20150104210919.GA22198@onelab2.iet.unipi.it>

next in thread | raw e-mail | index | archive | help
[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
luigi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150104210919.GA22198>