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: <cc91aa7d-0707-b64f-e7a9-f5ce97d4f313@6wind.com>
Date: Wed, 13 Sep 2023 09:58:08 +0200
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: Thomas Haller <thaller@...hat.com>, Benjamin Poirier
 <bpoirier@...dia.com>, David Ahern <dsahern@...nel.org>
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

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.

Regards,
Nicolas