Eric W. Biederman
ebiederm at xmission.com
Fri May 13 12:09:30 PDT 2005
"H. Peter Anvin" <hpa at zytor.com> writes:
> Eric W. Biederman wrote:
> > Sounds about right....
> > However it is simple to test if an interface plugged in,
> > with the mii code, and we should do that.
> > My gut feel is that the code should continue to try on multiple
> > interfaces but stop once n (n = 1?) seconds have passed since
> > it received a reply, that the kernel can used. This gives the
> > chance to pick the best DHCP reply, if you get several. But
> > more importantly is the trying on all of the interfaces until
> > something happens. Something stupid could have happened like
> > someone forgot to plug in the cable before turning on the
> > machine etc.
> The code is already parallel (which is good); so there isn't really a need to
> test the link. If we accept the first complete reply we get we
> should be OK.
Testing the link should allow us to avoid sending a DHCP packet
that will just be dropped and avoid doing exponential backoff when
the problem is the cable is not plugged in and not congestion.
> What do you mean with "best DHCP reply"?
Too much reading of the DHCP spec. :)
If we are doing nfs root then we want the nfs root path. If we get
a reply without the root path we can either discard the reply or a
use a default, but if shortly after that we get a reply with a root
path, there is a clear best.
In addition there are some options that allow precedence to defined
between DHCP servers. And I think that is mandatory in DHCPv6,
either that or it is only defined for DHCPv6.
I think waiting for the first DHCP packet should be good enough for
now. But ultimately there will be a choice of best packet.
More information about the klibc