Subject: Re: [Summer of Code] WiFi Browser - requirements
To: Ricardo Pinto <rncp@mega.ist.utl.pt>
From: Steven M. Bellovin <smb@cs.columbia.edu>
List: tech-net
Date: 06/07/2005 20:20:02
In message <20050607234239.BE10A3BFECD@berkshire.machshav.com>, "Steven M. Bell
ovin" writes:
>I would not try to do "automatic configuration of the interface"
>from this tool.  That's a complex process if done right -- see the 
>dhclient man page.  A better idea would be to use the omapi interface 
>to communicate with dhclient.  (Aside: a while ago, I posted a long 
>note on how I think that dhclient should interact with tools like this. 
>In particular, it needs to separate carrier detection from address 
>acquisition.  If anyone is interested, I'll post the note again.)
>

I did receive such a request, so here it is.

-----

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.


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