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]

Date: Wed, 13 Sep 2023 17:54:59 +0800
From: Hangbin Liu <liuhangbin@...il.com>
To: Nicolas Dichtel <nicolas.dichtel@...nd.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

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.

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/

Thanks
Hangbin