[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Design misfeature of dhclient for multiple interfaces
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
Certainly one approach. dhcpcd might handle this better, too.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Main Index |
Thread Index |