netdev - Re: [Questions] Some issues about IPv4/IPv6 nexthop route

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ZO1E4iy5hmd4kpHl@Laptop-X1>
Date: Tue, 29 Aug 2023 09:07:46 +0800
From: Hangbin Liu <liuhangbin@...il.com>
To: David Ahern <dsahern@...nel.org>
Cc: Ido Schimmel <idosch@...sch.org>,
	Stephen Hemminger <stephen@...workplumber.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>,
	Thomas Haller <thaller@...hat.com>
Subject: Re: [Questions] Some issues about IPv4/IPv6 nexthop route

On Mon, Aug 28, 2023 at 09:06:25AM -0600, David Ahern wrote:
> >>> But there are 2 issues here:
> >>> 1. the *type* and *protocol* field are actally ignored
> >>> 2. when do `ip monitor route`, the info dumpped in fib6_add_rt2node()
> >>>    use the config info from user space. When means `ip monitor` show the
> >>>    incorrect type and protocol
> >>>
> >>> So my questions are, should we show weight/scope for IPv4?
> > 
> > Here is the first one. As the weight/scope are not shown, the two separate
> > routes would looks exactly the same for end user, which makes user confused.
> 
> Asked and answered many times above: Weight has no meaning on single
> path routes; it is not even tracked if I recall correctly.

Yes, I'm sorry that I asked this question over and over again. Because I
always got the answer that these are two different routes and weight are
meaningless for none-multipath route. But IIRC, I never got a straight answer
of what we should deal with this problem.
> 
> > So why not just show the weight/scope, or forbid user to add a non-multipath
> > route with weight/scope?
> 
> That is a change to a uAPI we can not do at this point.

Yes, that's the answers I want to receive. Either show it, forbid it, or
not change it as it would change uAPI.

> 
> > 
> >>> How to deal the type/proto info missing for IPv6?
> > 
> > What we should do for this bug? The type/proto info are ignored when
> > merge the IPv6 nexthop entries.
> 
> I need more information; this thread has gone on for a long time now.

Sure, here is the reproducer:

+ ip link add dummy1 up type dummy
+ ip link add dummy2 up type dummy
+ ip addr add 2001:db8:101::1/64 dev dummy1
+ ip addr add 2001:db8:101::2/64 dev dummy2
+ ip monitor route
+ sleep 1
+ ip route add local 2001:db8:103::/64 via 2001:db8:101::10 dev dummy1 table 100
local 2001:db8:103::/64 via 2001:db8:101::10 dev dummy1 table 100 metric 1024 pref medium
+ ip route prepend unicast 2001:db8:103::/64 via 2001:db8:101::10 dev dummy2 table 100
2001:db8:103::/64 table 100 metric 1024 pref medium
        nexthop via 2001:db8:101::10 dev dummy2 weight 1
        nexthop via 2001:db8:101::10 dev dummy1 weight 1

   ^^ Here you can see the ip monitor print the route with unicast, even the
      "dev dummy1" route should be local

+ ip -6 route show table 100
local 2001:db8:103::/64 metric 1024 pref medium
        nexthop via 2001:db8:101::10 dev dummy1 weight 1
        nexthop via 2001:db8:101::10 dev dummy2 weight 1

    ^^ But the final route still keep using local. Which is different with
       what `ip monitor` print

+ ip route add 2001:db8:104::/64 via 2001:db8:101::10 dev dummy1 proto kernel table 200
2001:db8:104::/64 via 2001:db8:101::10 dev dummy1 table 200 proto kernel metric 1024 pref medium
+ ip route append 2001:db8:104::/64 via 2001:db8:101::10 dev dummy2 proto bgp table 200
2001:db8:104::/64 table 200 proto bgp metric 1024 pref medium
        nexthop via 2001:db8:101::10 dev dummy2 weight 1
        nexthop via 2001:db8:101::10 dev dummy1 weight 1
+ ip -6 route show table 200
2001:db8:104::/64 proto kernel metric 1024 pref medium
        nexthop via 2001:db8:101::10 dev dummy1 weight 1
        nexthop via 2001:db8:101::10 dev dummy2 weight 1

        ^^ Same here, ip monitor print protocol bgp, but the actual protocol
           is still kernel. We just merged them together and ignored the
           protocol field.

+ kill $!

As I asked, The type/proto info are ignored and dropped when merge the IPv6
nexthop entries. How should we deal with this bug? Fix it or ignore it?

Thanks
Hangbin