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

[Thomas Graf]

On 03/19/13 at 01:37pm, Roopa Prabhu wrote:
> Fix libnl to include additional attributes in the hash key depending
> on 'message type + msg flags'.
> ie In this case, use next hop info during lookup when ('msgtype ==
> RTM_NEWROUTE  && (msgflag == NLM_F_CREATE || 'msgflag &
> NLM_F_APPEND' || 'and more if needed'))

Why do we want to only regard the nexthop info if the append flag
is set? What's wrong with always comparing nexthops?

In fact, this looks like a kernel bug. The kernel should not
use different semantics in judging uniqueness based on netlink
flags.

> So, for the current problem, a few things to note here,
> 
> - Its unclear why this would work before the hash implementation
> went in, because even the linear search algorithm used before
> searched for similar attributes (ROUTE_ATTR_FAMILY | ROUTE_ATTR_TOS
> |
>                                    ROUTE_ATTR_TABLE | ROUTE_ATTR_DST).
> I am able to reproduce it even without the hash implementation.

Right, I think this is unrelated to the hash implementation.

> - If there is any problem with the hash implementation, i am willing
> to submit a patch to make the hash implementation optional. Settable
> via an api until I fix the real issue. However, for now it does not
> seem like that is the case. unless somebody confirms

Agreed.

> - We should probably add NLM_F_EXCL flag in nl-route-add.

Right, feel free to submit a patch.