[klibc] ipconfig

[Eric W. Biederman]

"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.

Eric