Re: adding existing ipv6 network route returns ENOMEM instead of EEXIST if loopback route also exists

Hi,

On 25/11/20 1:12 pm, Alexander V. Chernikov wrote:
> 21.11.2020, 22:48, "Guy Yur" <guyyur_at_gmail.com>:
>> Hi,
>>
>> When adding a route with a netmask, add_route() in route_ctl.c
>> adds the route with destination address masked.
>> If the add failed (for example, the route exists) it calls
>> lookup_prefix() with the original unmasked destination.
> Thank you for the report! Indeed, there is a problem w.r.t non-masked dst handling.
> I'll look into that in the end of this week.

Did you get a chance to look at it?

I am currently using a workaround of setting RTAX_DST to the masked address
before the call to lookup_prefix in add_route():

info->rti_info[RTAX_DST] = rt_key(rt);

/* addition failed. Lookup prefix in the rib to determine the cause */
rt_orig = lookup_prefix(rnh, info, &rnd_orig);

>> In a scenario where a loopback route was added followed
>> by the network route being added, if the network route
>> is added again and the network route destination is the
>> same as the loopback route, lookup_prefix() will match on
>> the loopback route, not finding the network route and
>> add_route() will return ENOMEM instead of EEXIST.
>> Adding the route with just the network part returns EEXIST as expected.
>>
>> Example:
>> # route -6 add -host fd53::1111 -prefixlen 128 ::1
>> # route -6 add -net fd53::1111 -prefixlen 64 ::1
>> # route -6 add -net fd53::1111 -prefixlen 64 ::1
>> route: writing to routing socket: Cannot allocate memory
>> add net fd53::1111: gateway ::1 fib 0: Cannot allocate memory
>> # route -6 add -net fd53:: -prefixlen 64 ::1
>> add net fd53::: gateway ::1 fib 0: route already in table
>>
>> I was testing https://reviews.freebsd.org/D15406
>> changes applied to r367863.
>> The changes call rtinit to add prefix route when
>> interface address is added/updated and uses the
>> interface address as the destination.
>> rtinit returned ENOMEM instead of EEXIST
>> causing dhcpcd to printCannot allocate memory.
>>
>> route commands above showing the problem were run
>> in r367863 without D15406 changesas well.
>>
>> Thanks,
>> Guy Yur
>>
>> _______________________________________________
>> freebsd-current_at_freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"

Thanks,
Guy Yur