netdev - Re: [PATCH net v2] net: lwtunnel: handle MTU calculation in forwading

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]

Date:   Sat, 26 Jun 2021 22:41:21 +0100
From:   Vadim Fedorenko <vfedorenko@...ek.ru>
To:     David Ahern <dsahern@...il.com>, David Ahern <dsahern@...nel.org>,
        netdev@...r.kernel.org, Roopa Prabhu <roopa@...dia.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net v2] net: lwtunnel: handle MTU calculation in forwading

On 26.06.2021 18:18, David Ahern wrote:
> [ added Roopa's nvidia address ]
> 
> On 6/25/21 10:21 AM, Vadim Fedorenko wrote:
>> Commit 14972cbd34ff ("net: lwtunnel: Handle fragmentation") moved
>> fragmentation logic away from lwtunnel by carry encap headroom and
>> use it in output MTU calculation. But the forwarding part was not
>> covered and created difference in MTU for output and forwarding and
>> further to silent drops on ipv4 forwarding path. Fix it by taking
>> into account lwtunnel encap headroom.
>>
>> The same commit also introduced difference in how to treat RTAX_MTU
>> in IPv4 and IPv6 where latter explicitly removes lwtunnel encap
>> headroom from route MTU. Make IPv4 version do the same.
>>
>> Fixes: 14972cbd34ff ("net: lwtunnel: Handle fragmentation")
>> Suggested-by: David Ahern <dsahern@...il.com>
>> Signed-off-by: Vadim Fedorenko <vfedorenko@...ek.ru>
>> ---
>>   include/net/ip.h        | 12 ++++++++----
>>   include/net/ip6_route.h | 16 ++++++++++++----
>>   net/ipv4/route.c        |  3 ++-
>>   3 files changed, 22 insertions(+), 9 deletions(-)
>>
> 
> 
> I think this is the right approach - tunnel overhead should always be
> considered for the mtu. Did you run the pmtu.sh selftests to make sure
> those still work?
> 

Actually not, I was running my own tests of routing configurations with 
different types of tunnels like GRE, GUE and FOU with mpls lwtunnels to check 
consistency of calculated mtus.

Will re-run pmtu.sh but I my installation doesn't support OVS right now.

Also, I was thinking about this RTAX_MTU and I'm really in doubt. Do we actually 
want the situation when
   ip route A.B.C.D/32 encap mpls 100 dev ip6tnl1 mtu 1400
will actually require mtu=1396? Because this looks like not clear for users I 
suppose.