Re: Design misfeature of dhclient for multiple interfaces

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Mon, 8 Sep 2008 21:38:05 -0400
"matthew sporleder" <msporleder%gmail.com@localhost> wrote:

> On 9/8/08, Steven M. Bellovin <smb%cs.columbia.edu@localhost> wrote:
> > The other day, my daughter ran into a design misfeature of dhclient
> >  that I suspect generalizes.  Her laptop (running 4.0, but that
> > isn't relevant) had wm and ath interfaces configured.  The wm
> > interface got a lease right away, and set up a default route and
> >  modified /etc/resolv.conf.  When ath0 got a lease, the attempt to
> > set a default route of course failed, but it overwrote resolv.conf
> > with the new data.  However -- the wireless net was in 1918 space,
> > and packets sent via the default route couldn't reach the name
> > servers.  Her machine was thus left without working name resolution.
> >
> >  The underlying problem is that an entire group of attributes --
> > source address, default route, name servers, time servers, etc.,
> > are all bound together.  If there's any sort of routing or access
> > control barrier between the two different nets -- access
> > restrictions on recursive name servers, for example -- the fact
> > that they don't share fate, and that there's one obvious place
> > where one will fail and the others succeed can cause trouble.
> >
> 
> This all sounds similar to your previous messages about dhclient and
> the default route when networks changed.

Funny about that...  This, however, is a new incident.
> 
> I wouldn't mind seeing routes, resolv.conf, time servers, incoming
> traffic, etc all be bound to a specific interface which would
> eventually (although not necessarily) fall back to a "system-wide
> default."
> 
Certainly one approach.  dhcpcd might handle this better, too.

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