Design misfeature of dhclient for multiple interfaces

[Steven M. Bellovin]

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.

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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[matthew sporleder]

Post by Steven M. Bellovin
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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Mon, 8 Sep 2008 21:38:05 -0400

Post by matthew sporleder

Post by Steven M. Bellovin
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.

Post by matthew sporleder
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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Steven M. Bellovin
Certainly one approach. dhcpcd might handle this better, too.

It does! But currently only for Linux.
Linux has route metrics, which means that you can install multiple
routes to the same destination. See attached route output for an
example.
re0 is wired, ral0 is wireless. As re0 has the lower metric it will be
the preferred route. The kernel takes care of everything :)

No BSD currently supports route metrics, which poses a problem. To be
able to solve this, dhcpcd needs to work like dhclient and have one
instance handling multiple interfaces (dhcpcd-4 and earlier are single
instance per interface by design). This has already been done and works
very well. The code is also a lot smaller and whilst memory usage for
the instance has increased (duh - more interfaces == more memory) it's
still more efficient than dhclient by quite some margin.

I'll email tech-net@ when this is done so I can get some testing done.
Should be done somewhere over the next few days or weeks - prod me if I
take a bit longer ;)

Thanks

Roy

[matthew sporleder]

Post by Roy Marples

Post by Steven M. Bellovin
Certainly one approach. dhcpcd might handle this better, too.

It does! But currently only for Linux.
Linux has route metrics, which means that you can install multiple
routes to the same destination. See attached route output for an
example.
re0 is wired, ral0 is wireless. As re0 has the lower metric it will be
the preferred route. The kernel takes care of everything :)
No BSD currently supports route metrics, which poses a problem. To be
able to solve this, dhcpcd needs to work like dhclient and have one
instance handling multiple interfaces (dhcpcd-4 and earlier are single
instance per interface by design). This has already been done and works
very well. The code is also a lot smaller and whilst memory usage for
the instance has increased (duh - more interfaces == more memory) it's
still more efficient than dhclient by quite some margin.
Should be done somewhere over the next few days or weeks - prod me if I
take a bit longer ;)

I've used that feature of linux before and it is handy (although it
only addresses routes and not resolv.conf, etc), but until that
feature is available on netbsd would it be possible to fail all config
changes if one of them doesn't work? (or even better- arbitrarily
group them per config?)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by matthew sporleder
I've used that feature of linux before and it is handy (although it
only addresses routes and not resolv.conf, etc), but until that
feature is available on netbsd would it be possible to fail all config
changes if one of them doesn't work? (or even better- arbitrarily
group them per config?)

That would mean that the interface wouldn't be re-configured until the
acquired lease expired, which doesn't really help much.

However, dhcpcd-4.0 did get one final feature before it went stable
which is of use here. Namely, it can save config's per interface. Out of
the box, it knows about resolv.conf and ntpd.conf. It can also merge
configs - with resolv.conf it has a mini resolvconf [1] implementation
and for ntpd.conf it builds a list of NTP servers to append to the
main /etc/ntpd.conf.

Maybe you should try dhcpcd-4.0.1 in pkgsrc/wip.
If it works for you (it should at least mitigate if not completely solve
your issue here) then maybe request that NetBSD merges it into -current?
That would be a good thing as dhcpcd has got a few imporant fixes from
the version it current has. It obviously won't solve the default route
issue, but that is being worked on.

Thanks

Roy


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Thu, 11 Sep 2008 07:21:57 +1000

Post by Daniel Carosone

Post by Steven M. Bellovin
I think there are several separate issues. One is fail-over, which
is indeed important. A second is what to do when there are multiple
interfaces, which has several aspects: which has priority, when are
leases negotiated, how is auxiliary data bound to the current
default route, etc. My current failure is with this last point,
though (as has been noted) I'm still grasping for a solution to all
of them.

The cheesy approach might work; it's not suitable for all
requirements, but does pretty well for the common case: disable
wireless when there's a wired connection. Some ifwatchd scripts
should deal with that, including making dhcp release and renew leases
after a change (so the right *.conf contents are left at the end).

I don't think we're very far from what we really need, at least for
simple cases; as best I can tell, Ubuntu does much more of the right
thing (again, for simple cases) with ISC dhclient.


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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Roy Marples
It can also merge
configs - with resolv.conf it has a mini resolvconf [1] implementation

*Ahem*

[1] http://roy.marples.name/openresolv

:)

You can find openresolv in pkgsrc/wip

Thanks

Roy


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Tue, 09 Sep 2008 14:28:13 +0100

Post by Roy Marples

Post by matthew sporleder
I've used that feature of linux before and it is handy (although it
only addresses routes and not resolv.conf, etc), but until that
feature is available on netbsd would it be possible to fail all
config changes if one of them doesn't work? (or even better-
arbitrarily group them per config?)

That would mean that the interface wouldn't be re-configured until the
acquired lease expired, which doesn't really help much.
However, dhcpcd-4.0 did get one final feature before it went stable
which is of use here. Namely, it can save config's per interface. Out
of the box, it knows about resolv.conf and ntpd.conf. It can also
merge configs - with resolv.conf it has a mini resolvconf [1]
implementation and for ntpd.conf it builds a list of NTP servers to
append to the main /etc/ntpd.conf.
Maybe you should try dhcpcd-4.0.1 in pkgsrc/wip.
If it works for you (it should at least mitigate if not completely
solve your issue here) then maybe request that NetBSD merges it into
-current? That would be a good thing as dhcpcd has got a few imporant
fixes from the version it current has. It obviously won't solve the
default route issue, but that is being worked on.

I think there are several separate issues. One is fail-over, which is
indeed important. A second is what to do when there are multiple
interfaces, which has several aspects: which has priority, when are
leases negotiated, how is auxiliary data bound to the current default
route, etc. My current failure is with this last point, though (as has
been noted) I'm still grasping for a solution to all of them.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Daniel Carosone]

Post by Steven M. Bellovin
I think there are several separate issues. One is fail-over, which is
indeed important. A second is what to do when there are multiple
interfaces, which has several aspects: which has priority, when are
leases negotiated, how is auxiliary data bound to the current default
route, etc. My current failure is with this last point, though (as has
been noted) I'm still grasping for a solution to all of them.

The cheesy approach might work; it's not suitable for all
requirements, but does pretty well for the common case: disable
wireless when there's a wired connection. Some ifwatchd scripts
should deal with that, including making dhcp release and renew leases
after a change (so the right *.conf contents are left at the end).

--
Dan.

[Roy Marples]

Post by Roy Marples

Post by Steven M. Bellovin
Certainly one approach. dhcpcd might handle this better, too.

It does! But currently only for Linux.
Linux has route metrics, which means that you can install multiple
routes to the same destination. See attached route output for an
example.
re0 is wired, ral0 is wireless. As re0 has the lower metric it will be
the preferred route. The kernel takes care of everything :)
No BSD currently supports route metrics, which poses a problem. To be
able to solve this, dhcpcd needs to work like dhclient and have one
instance handling multiple interfaces (dhcpcd-4 and earlier are single
instance per interface by design). This has already been done and works
very well. The code is also a lot smaller and whilst memory usage for
the instance has increased (duh - more interfaces == more memory) it's
still more efficient than dhclient by quite some margin.
Should be done somewhere over the next few days or weeks - prod me if I
take a bit longer ;)

This is now done - well mostly :)
You can download a snapshot here [1] and use the rc.d script [2] as
well. Don't enable ifconfig_xxx=dhcp.

The only things left to do are change the subnet route for the preferred
interface address and expire the lease when the link goes and re-request
it comes back up. This maybe done over the weekend, if not next week.

BTW, this is a very experimental version, ware bugs or broken features!
Check the man pages for changes.

Thanks

Roy

[1]
http://git.marples.name/?p=dhcpcd.git;a=snapshot;h=2679757e86f965a8732b9b4400cf3a7da065299c;sf=tgz

[2] http://roy.marples.name/dhcpcd/dhcpcd.rc


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Roy Marples

Post by Roy Marples

Post by Steven M. Bellovin
Certainly one approach. dhcpcd might handle this better, too.

It does! But currently only for Linux.
Linux has route metrics, which means that you can install multiple
routes to the same destination. See attached route output for an
example.
re0 is wired, ral0 is wireless. As re0 has the lower metric it will be
the preferred route. The kernel takes care of everything :)
No BSD currently supports route metrics, which poses a problem. To be
able to solve this, dhcpcd needs to work like dhclient and have one
instance handling multiple interfaces (dhcpcd-4 and earlier are single
instance per interface by design). This has already been done and works
very well. The code is also a lot smaller and whilst memory usage for
the instance has increased (duh - more interfaces == more memory) it's
still more efficient than dhclient by quite some margin.
Should be done somewhere over the next few days or weeks - prod me if I
take a bit longer ;)

This is now done - well mostly :)
You can download a snapshot here [1] and use the rc.d script [2] as
well. Don't enable ifconfig_xxx=dhcp.
The only things left to do are change the subnet route for the preferred
interface address and expire the lease when the link goes and re-request
it comes back up. This maybe done over the weekend, if not next week.
BTW, this is a very experimental version, ware bugs or broken
features!
Check the man pages for changes.

And this in turn is now done - you can swap between wired and wireless
on the same subnet and dhcpcd manages the routing just fine.

It's now getting quite stable, so I've released an experimental version
[1] with rc.d script [2] so I can get some feedback.
Use the command
netstat -nr -f inet
to verify the routing changes to the right interface.

You may wish to add this line to /etc/dhcpcd.conf
denyinterfaces fwip[0-9]* tap[0-9]*
to stop dhcpcd from managing those interfaces.

Let me know how it works for you :)

Thanks

Roy

[1] http://roy.marples.name/dhcpcd/dhcpcd-4.99.1.tar.bz2
[2] http://roy.marples.name/dhcpcd/dhcpcd.rc



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de