[Bug report] Unable to remove 'default' routes using the CLI tools

Tony Cheneau tony.cheneau at amnesiak.org
Tue Feb 5 17:43:13 EST 2013


Hello,

For my own purposes, I'm building a bunch of python wrappers around 
libraries exposed by CLI tools (that is the functions exposed in the 
netlink/cli directory). To be more precise, I'm using cython to glue the 
libnl C code within a python wrapper. While performing my tests, I found 
out a odd behavior when playing with default routes: I could not always 
remove them. To me, it qualifies as a bug, but it might be an intended 
behavior. This issue is also present with the nl-route-delete binary, so 
I'll use this tool for my bug report. Finally, I must add that I'm using 
the current git tree tip.

So, first step is to add multiple default routes (lines starting with # 
are indicates the command I inputted):
# ./nl-route-add  -d default -n via=10.0.0.3,dev=eth0
Added inet default via 10.0.0.3 dev eth0
# ./nl-route-add  -d default -n via=10.0.0.2,dev=eth0
Added inet default via 10.0.0.2 dev eth0
# ./nl-route-add  -d default -n via=10.0.0.1,dev=eth0
Added inet default via 10.0.0.1 dev eth0

Then I try listing current routes:
# ./nl-route-list|grep default
inet default table main type unicast via 10.0.20.200 dev eth0
inet6 default table unspec type unreachable via dev lo

I find it weird enough that the route does not show up. Only the 
initial route to my default gateway shows up (it was set before I run 
any of the previous commands).
However, if I try adding a route again, I obtain the following message 
(that would indicate that the previous commands went through):
# ./nl-route-add  -d default -n via=10.0.0.1,dev=eth0
Error: Unable to add route: Object exists

Now, this is the part that motivates me to write this bug report, if I 
try to remove the default routes using symmetrical command 
"nl-route-delete", I obtain the following:
# ./nl-route-delete  -d default -n via=10.0.0.3,dev=eth0
Deleted 0 routes
# ./nl-route-delete  -d default -n via=10.0.0.2,dev=eth0
Deleted 0 routes
# ./nl-route-delete  -d default -n via=10.0.0.1,dev=eth0
Deleted 0 routes

However, if I remove the next-hop selector, it works (I omitted the 
part when I removed my default gateway, because I lost connection on 
this one and could not retrieve the output):
# ./nl-route-delete -d default
Deleted inet default table main type unicast via 10.0.0.3 dev eth0
Deleted 1 routes
# ./nl-route-delete -d default
Deleted inet default table main type unicast via 10.0.0.2 dev eth0
Deleted 1 routes
# ./nl-route-delete -d default
Deleted inet default table main type unicast via 10.0.0.1 dev eth0
Deleted 1 routes

It also works if I reverse the ordering when removing routes (when no 
default gateway is set):
# ./nl-route-add  -d default -n via=10.0.0.3,dev=eth0
Added inet default via 10.0.0.3 dev eth0
# ./nl-route-add  -d default -n via=10.0.0.2,dev=eth0
Added inet default via 10.0.0.2 dev eth0
# ./nl-route-add  -d default -n via=10.0.0.1,dev=eth0
Added inet default via 10.0.0.1 dev eth0
# ./nl-route-delete  -d default -n via=10.0.0.1,dev=eth0
Deleted 0 routes
# ./nl-route-delete  -d default -n via=10.0.0.3
Deleted inet default table main type unicast via 10.0.0.3 dev eth0
Deleted 1 routes
# ./nl-route-delete  -d default -n via=10.0.0.2
Deleted inet default table main type unicast via 10.0.0.2 dev eth0
Deleted 1 routes
# ./nl-route-delete  -d default -n via=10.0.0.1
Deleted inet default table main type unicast via 10.0.0.1 dev eth0
Deleted 1 routes

The same phenomena seems to occur when using IPv6 addresses.

(As a side note, I wanted to add that I'm aware of the various python 
bindings existing for libnl, but, to the best of my knowledge, none of 
them seems to control the netlink "route" sub-system that I need.)

Regards,
Tony Cheneau



More information about the libnl mailing list