[oe] default route handling of udhcpc

Phil Blundell philb at gnu.org
Mon Nov 7 10:11:36 UTC 2011


On Mon, 2011-11-07 at 09:13 +0100, Steffen Sledz wrote:
> Recently we hit a problem with the default route handling of udhcpc.
> 
> The provided script busybox/files/simple.script (aka /etc/udhcpc.d/50default) removes all existing default routes before setting new routes. I think that's wrong.
> 
> If multiple interfaces offer default routes (via DHCP, static config, or any other way) there is no reason to prefer one over another (without having any additional information). So the script should only add the new default route. A short search in the internet brings up a lot of useful scenarios for multiple default routes.
> 
> So i tried to remove the part from the script which removes the existing routes. This led to a confusing situation.
> 
> If the script uses "route add default gw ..." (which is the case if /sbin/ip is not installed) everything seems to work fine.
> 
> But if /sbin/ip (from the busybox package) is installed the "ip route add default via ..." results in an "ip: RTNETLINK answers: File exists" error. In my opinion this is an error in the busybox ip implementation.

It's not a defect in busybox ip; this is the intended behaviour of "ip
route add" and iproute2 behaves the same.  If you want multiple routes
for the same destination then you need to use "ip route append" instead.
Arguably it is a defect in "route" that you are allowed to set multiple
equivalent routes without having to specify any ordering but, given that
"route" is old and obsolescent, I am not too enthusiastic about trying
to fix it.

As to whether it makes sense for the default script to tear down old
routes, my view is that the current behaviour probably is the correct
default.  Wanting to use multiple default routes is a fairly unusual
case and anybody who does want to do that is probably capable of writing
a custom script for whatever their installation requires.  Whereas, if
dhcpcd were to leave old routes in place by default, you would probably
end up with naive users getting stale routes left around when switching
between networks and ending up with hard-to-debug connectivity problems.

p.






More information about the Openembedded-devel mailing list