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
| ||
|
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.
Powered by blists - more mailing lists