tech-net archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Design misfeature of dhclient for multiple interfaces
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.
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."
Matt
Home |
Main Index |
Thread Index |
Old Index