netdev - Re: [PATCH net v2 1/2] ipv6: Honor route mtu if it is within limit of dev mtu

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: <CANP3RGfGcr25cjnrUOdaH1rG9S9uY8uS80USXeycDBhbsX9CZw@mail.gmail.com>
Date:   Wed, 15 Jun 2022 18:21:07 -0700
From:   Maciej Żenczykowski <maze@...gle.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Subash Abhinov Kasiviswanathan <quic_subashab@...cinc.com>,
        "David S. Miller" <davem@...emloft.net>,
        David Ahern <dsahern@...nel.org>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Linux NetDev <netdev@...r.kernel.org>,
        Stefano Brivio <sbrivio@...hat.com>,
        Kaustubh Pandey <quic_kapandey@...cinc.com>,
        Sean Tranchetti <quic_stranche@...cinc.com>
Subject: Re: [PATCH net v2 1/2] ipv6: Honor route mtu if it is within limit of
 dev mtu

On Wed, Jun 15, 2022 at 5:35 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Mon, 13 Jun 2022 23:01:54 -0600 Subash Abhinov Kasiviswanathan wrote:
> > When netdevice MTU is increased via sysfs, NETDEV_CHANGEMTU is raised.
> >
> > addrconf_notify -> rt6_mtu_change -> rt6_mtu_change_route ->
> > fib6_nh_mtu_change
> >
> > As part of handling NETDEV_CHANGEMTU notification we land up on a
> > condition where if route mtu is less than dev mtu and route mtu equals
> > ipv6_devconf mtu, route mtu gets updated.
> >
> > Due to this v6 traffic end up using wrong MTU then configured earlier.
> > This commit fixes this by removing comparison with ipv6_devconf
> > and updating route mtu only when it is greater than incoming dev mtu.
> >
> > This can be easily reproduced with below script:
> > pre-condition:
> > device up(mtu = 1500) and route mtu for both v4 and v6 is 1500
> >
> > test-script:
> > ip route change 192.168.0.0/24 dev eth0 src 192.168.0.1 mtu 1400
> > ip -6 route change 2001::/64 dev eth0 metric 256 mtu 1400
> > echo 1400 > /sys/class/net/eth0/mtu
> > ip route change 192.168.0.0/24 dev eth0 src 192.168.0.1 mtu 1500
> > echo 1500 > /sys/class/net/eth0/mtu
>
> CC maze, please add him if there is v3
>
> I feel like the problem is with the fact that link mtu resets protocol
> MTUs. Nothing we can do about that, so why not set link MTU to 9k (or
> whatever other quantification of infinity there is) so you don't have
> to touch it as you discover the MTU for v4 and v6?
>
> My worry is that the tweaking of the route MTU update heuristic will
> have no end.
>
> Stefano, does that makes sense or you think the change is good?

I vaguely recall that if you don't want device mtu changes to affect
ipv6 route mtu, then you should set 'mtu lock' on the routes.
(this meaning of 'lock' for v6 is different than for ipv4, where
'lock' means transmit IPv4/TCP with Don't Frag bit unset)