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: <b6837627-27a9-b870-c85b-799c23705a74@kernel.org>
Date: Wed, 13 Sep 2023 08:41:05 -0600
From: David Ahern <dsahern@...nel.org>
To: nicolas.dichtel@...nd.com, Thomas Haller <thaller@...hat.com>,
 Benjamin Poirier <bpoirier@...dia.com>
Cc: Stephen Hemminger <stephen@...workplumber.org>,
 Hangbin Liu <liuhangbin@...il.com>, 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

On 9/13/23 1:58 AM, 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)

carrier down is a link event and as you show here, link events are sent.

> 
> 'ip nexthop' and 'ip route' show that the nexthop and the route have been deleted.

nexthop objects are removed on the link event; any routes referencing
those nexthops are removed.

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

compat_mode is about expanding nhid into the full, legacy route
attributes. See 4f80116d3df3b