netdev - Re: [PATCH net-next] ipv4/fib: send RTM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e2b57bea-fb14-cef4-315a-406f0d3a7e4f@6wind.com>
Date: Wed, 13 Sep 2023 16:11:57 +0200
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: Hangbin Liu <liuhangbin@...il.com>
Cc: Thomas Haller <thaller@...hat.com>, Benjamin Poirier
 <bpoirier@...dia.com>, David Ahern <dsahern@...nel.org>,
 Stephen Hemminger <stephen@...workplumber.org>,
 Ido Schimmel <idosch@...sch.org>, netdev@...r.kernel.org,
 "David S . Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net-next] ipv4/fib: send RTM_DELROUTE notify when flush
 fib

Le 13/09/2023 à 11:54, Hangbin Liu a écrit :
> On Wed, Sep 13, 2023 at 09:58:08AM +0200, Nicolas Dichtel wrote:
>> Le 11/09/2023 à 11:50, Thomas Haller a écrit :
>> [snip]
>>> - the fact that it isn't fixed in more than a decade, shows IMO that
>>> getting caching right for routes is very hard. Patches that improve the
>>> behavior should not be rejected with "look at libnl3 or FRR".
>> +1
>>
>> I just hit another corner case:
>>
>> ip link set ntfp2 up
>> ip address add 10.125.0.1/24 dev ntfp2
>> ip nexthop add id 1234 via 10.125.0.2 dev ntfp2
>> ip route add 10.200.0.0/24 nhid 1234
>>
>> Check the config:
>> $ ip route
>> <snip>
>> 10.200.0.0/24 nhid 1234 via 10.125.0.2 dev ntfp2
>> $ ip nexthop
>> id 1234 via 10.125.0.2 dev ntfp2 scope link
>>
>>
>> Set the carrier off on ntfp2:
>> ip monitor label link route nexthop&
>> ip link set ntfp2 carrier off
>>
>> $ ip link set ntfp2 carrier off
>> $ [LINK]4: ntfp2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state
>> DOWN group default
>>     link/ether de:ed:02:67:61:1f brd ff:ff:ff:ff:ff:ff
>>
>> => No nexthop event nor route event (net.ipv4.nexthop_compat_mode = 1)
>>
>> 'ip nexthop' and 'ip route' show that the nexthop and the route have been deleted.
>>
>> If the nexthop infra is not used (ip route add 10.200.0.0/24 via 10.125.0.2 dev
>> ntfp2), the route entry is not deleted.
>>
>> I wondering if it is expected to not have a nexthop event when one is removed
>> due to a carrier lost.
>> At least, a route event should be generated when the compat_mode is enabled.
> 
> This thread goes to a long discussion.
> 
> Ido has bringing up this issue[1]. In my patchv2[2] we skipped to send the
> notification as it is deliberate.
The compat_mode was introduced for daemons that doesn't support the nexthop
framework. There must be a notification (RTM_DELROUTE) when a route is deleted
due to a carrier down event. Right now, the backward compat is broken.

> 
> BTW, I'm still looking into the questions you asked in my IPv6 patch[3]. Sorry
> for the late response. I was busy with some other stuff recently.
> 
> [1] https://lore.kernel.org/netdev/ZLlE5of1Sw1pMPlM@shredder/
> [2] https://lore.kernel.org/netdev/20230809140234.3879929-3-liuhangbin@gmail.com/
> [3] https://lore.kernel.org/netdev/bf3bb290-25b7-e327-851a-d6a036daab03@6wind.com/
Thank you for the pointers.


Regards,
Nicolas