Subject: dhclient design (was: WEP support for atu device)
To: Stephen Borrill <netbsd@precedence.co.uk>
From: Steven M. Bellovin <smb@cs.columbia.edu>
List: netbsd-users
Date: 01/19/2007 14:35:33
On Fri, 19 Jan 2007 19:15:09 +0000 (GMT)
Stephen Borrill <netbsd@precedence.co.uk> wrote:
> On Fri, 19 Jan 2007, Steven M. Bellovin wrote:
> [snip]
> > 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!)
>
> This sounds like a better solution to the workaround we've
> implemented (but hey, it works for us!):
> http://mail-index.netbsd.org/netbsd-help/2006/12/17/0001.html
>
> We check link status _before_ calling dhclient which is alright in
> certain circumstances, but I really like the request new lease if
> carrier drops idea.
>
I'm pretty sure I once posted this to a NetBSD list, but I can't
remember when. So -- here's a more complete (though still high-level)
design for how I think it should work.
------
---
Here is an informal sketch of how I think dhclient should work. The
fundamental point is that I want to separate carrier detection
from address and parameter assignment. Note carefully that this
permits bringing PPP into this model, though there you'd use IPCP
instead of DHCP for address and parameter assignment.
One metanote: the entire process is driven by a configuation file
that has to be easily selectable -- you may be on an airplane and want
to shut down your wireless card, or you know that the local Ethernet
has no router, so you don't care if there's carrier.
Second, there are two different priorities, a carrier priority and
a parameter priority. Different elements can have the same carrier
priority; they cannot have the same parameter priority.
The first stage is to acquire carrier on all networks with the
current highest priority. If a a new network interface appears,
it's added to the list. The process of acquiring carrier is an
active one; it may involve dialing a PPP link, trying different
SSIDs or WEP keys, etc. When all links at the top priority have
carrier, that process stops trying to acquire more carriers, though
it needs to monitor for carrier drop. (Note: carrier up/down events
need to be debounced. Note also the unsolved problem: how do you
monitor for a higher-priority WEP key when you've associated with
an access point using a lower priority one.)
When an interface has carrier, an attempt is made to acquire an
address for it. This may be static, IPCP, or DHCP. For the latter,
the old lease used is determined by the carrier type -- I don't
want to ask to renew my office IP address lease when I'm on a hotel
network.
Addresses are assigned immediately. Parameters -- default route,
DNS servers, etc. -- are based on priority. When a higher priority
interface
Consider a laptop with a wired and a wireless interface, where the
two interfaces are on different IP networks. You could have equal
carrier priorities, and would assign each interface its own IP address.
But the wired link would have a higher parameter priority, so that
it would have the default route (and hence be used for source address
selection, given the usual rules). If you unplug the Ethernet cable,
the system could switch instantly (modulo debounce time) to the wireless
link, since all parameters would already have been acquired.
If the wireless and wired links are on the same network, you don't
want to do that, since you might answer ARPs inappropriately. In that
case, you'd give the wireless link a lower carrier priority, so it
wouldn't be used at all if the wired link was plugged in. (But we need
some fallback, in case you can't get an address on the wired link.)
Now consider a router with dial backup. When the Ethernet link
fails -- and you could even have a higher-level process declaring
failure based on reachability -- the process that acquires carrier
on the dial-up link is started. If the Ethernet comes back, the
dial-up link is dropped.
I haven't worked out all the details, and there's a lot of opportunity
here for too much complexity. That said, I think it's a starting
point for a discussion.