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