On Fri, 19 Jan 2007 08:42:24 -0700
"Andy Ruhl" <acruhl@gmail.com> wrote:

> 
> I recently setup one of my adapters with dhcp, which I'd never done
> before, and I noticed that the fewer options I used it decided to
> connect. If it doesn't work, it might be a bug I suppose.
> 
Let me rant about dhclient again.

First, a metanote.  Most of the OS-specific operations are performed
by dhclient-script.  There's also a "toss it over the wall" approach to
things like layer 2 configuration and carrier detection.  Media options
are set by calling dhclient-script with $reason set to MEDIUM; the
script does a 1-second sleep and then returns.

The problem is that changing such options frequently causes a lengthy
negotiation and/or signal acquisition process, possibly (depending on
the driver) made worse by a NIC reset (as best I can tell).  It seems
to invoke the script frequently, and it doesn't check if the new
setting is the same as the old one.  This seems to result in constant
reinitiations of the link-layer negotiation.  If you leave out any media
options, and instead issue the appropriate commands manually, you may
be in much better shape if your network takes a while to be acquired by
the NIC.

I've temporarily changed the 'sleep 1' to 'sleep 5' in the MEDIUM
section, to accommodate a new GigE switch.  That seems to have helped.
I expect it will also help me with 802.11, where I've long had such
problems.  But fundamentally, dhclient needs a fundamental
restructuring to make it know more about link-level carrier; it
shouldn't initiate IP-level requests until it has carrier, and it
should request a new lease if carrier drops and is reacquired.  (This
last step needs debouncing!)



		--Steve Bellovin, http://www.cs.columbia.edu/~smb