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

[Roopa Prabhu]

On 3/21/13 11:09 AM, Thomas Graf wrote:
> 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?

I pointed out nexthop because in tony's problem, only nexthop attribute 
was different between the two routes. It could have been any other 
attribute like scope, type etc.

I think our current key attributes are correct. Kernel also seems to use 
the same during lookup. However, I was trying to say that after lookup 
we should probably use more attributes to compare the objects than 
simply nl_object identical. We could use nl_object_diff or a variant 
depending on whether kernel appended, replaced or created a fresh route. 
At this point i am afraid adding more attributes in the lookup might 
break something else.
I will think about this some more and also look at the kernel code again.

>
> 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.

I will submit a patch.

Thanks.