On Jan 19, 2007, at 8:48 AM, Steven M. Bellovin wrote:
> 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!)

dhclient ought to register for interface link-state changes and other  
significant routing events via the messaging facility NetBSD  
hopefully has in "man 4 route" such as RTM_ADD, RTM_DELETE,  
RTM_CHANGE, RTM_IFINFO, RTM_IFANNOUNCE.

There's some extensive documentation and experiences from people  
implementing Zeroconf with regard to the interactions between DHCP  
and link-local IPv4 addresses here which is also relevant to handling  
interface state changes:

   http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt

"2.2. Claiming a Link-Local Address

     After it has selected an IPv4 Link-Local address, a host MUST  
test to
     see if the IPv4 Link-Local address is already in use before  
beginning
     to use it. When a network interface transitions from an inactive to
     an active state, the host does not have knowledge of what IPv4  
Link-
     Local addresses may currently be in use on that link, since the  
point
     of attachment may have changed or the network interface may have  
been
     inactive when a conflicting address was claimed.

     Were the host to immediately begin using an IPv4 Link-Local address
     which is already in use by another host, this would be  
disruptive to
     that other host. Since it is possible that the host has changed its
     point of attachment, a routable address may be obtainable on the  
new
     network, and therefore it cannot be assumed that an IPv4 Link-Local
     address is to be preferred.

     Before using the IPv4 Link-Local address (e.g. using it as the  
source
     address in an IPv4 packet, or as the Sender IPv4 address in an ARP
     packet) a host MUST perform the probing test described below to
     achieve better confidence that using the IPv4 Link-Local address  
will
     not cause disruption.

     Examples of events that involve an interface becoming active  
include:

        Reboot/startup
        Wake from sleep (if network interface was inactive during sleep)
        Bringing up previously inactive network interface
        IEEE 802 hardware link-state change (appropriate for the
             media type and security mechanisms which apply) indicates
             that an interface has become active.
        Association with a wireless base station or adhoc network.

     A host MUST NOT perform this check periodically as a matter of
     course. This would be a waste of network bandwidth, and is
     unnecessary due to the ability of hosts to passively discover
     conflicts, as described in Section 2.5."

...and then it details the specific way to perform an ARPOP_REQUEST  
probe that all hosts on the local subnet will see without polluting  
their arp cache with wrong IP info.  This type of ARP probing could  
also be used by dhclient to see whether something like a wireless  
connection bouncing down and then back up ends up with usable network  
connectivity without having to acquire a new DHCP lease.

--
-Chuck