| Message ID | 20200624114852.GA153778@tws |
|---|---|
| State | New |
| Headers | show |
| Series | IPv4: Tunnel: Fix effective path mtu calculation | expand |
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c index f4f1d11eab50..871d28bd29fa 100644 --- a/net/ipv4/ip_tunnel.c +++ b/net/ipv4/ip_tunnel.c @@ -495,8 +495,7 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb, pkt_size = skb->len - tunnel_hlen - dev->hard_header_len; if (df) - mtu = dst_mtu(&rt->dst) - dev->hard_header_len - - sizeof(struct iphdr) - tunnel_hlen; + mtu = dst_mtu(&rt->dst) - sizeof(struct iphdr) - tunnel_hlen; else mtu = skb_valid_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
The calculation of the effective tunnel mtu, that is used to create mtu exceptions if necessary, is currently not done correctly. This leads to unnecessary entries in the IPv6 route cache for any packet to be sent through the tunnel. The root cause is, that "dev->hard_header_len" is subtracted from the tunnel destinations path mtu. Thus subtracting too much, if dev->hard_header_len is filled in. This is that case for SIT tunnels where hard_header_len is the underlyings dev's hard_header_len (e.g. 14 for ethernet) + 20 bytes IP header (see net/ipv6/sit.c:1091). However, the MTU of the path is exclusive of the ethernet header and the 20 bytes for the IP header are being subtracted separately already. Thus hard_header_len is removed from this calculation. For IPIP and GRE tunnels this doesn't change anything as hard_header_len is zero in those cases anyways. Signed-off-by: Oliver Herms <oliver.peter.herms@gmail.com> --- net/ipv4/ip_tunnel.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)