| Message ID | 20210105231523.622-4-fw@strlen.de |
|---|---|
| State | New |
| Headers | show |
| Series | None | expand |
Hello Florian, On Wed, Jan 06, 2021 at 00:15:23 +0100, Florian Westphal wrote: > Force refragmentation as per original sizes unconditionally so ip tunnel > will encapsulate the fragments instead. [...] > diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c > index 89fff5f59eea..2ed0b01f72f0 100644 > --- a/net/ipv4/ip_output.c > +++ b/net/ipv4/ip_output.c > @@ -302,7 +302,7 @@ static int __ip_finish_output(struct net *net, struct sock *sk, struct sk_buff * > if (skb_is_gso(skb)) > return ip_finish_output_gso(net, sk, skb, mtu); > > - if (skb->len > mtu || (IPCB(skb)->flags & IPSKB_FRAG_PMTU)) > + if (skb->len > mtu || IPCB(skb)->frag_max_size) > return ip_fragment(net, sk, skb, mtu, ip_finish_output2); > > return ip_finish_output2(net, sk, skb); > -- > 2.26.2 Did some tests yesterday and I can confirm that this patch fixes the problem for both IPIP tunnel and XFRM tunnel interfaces. Thanks for the fix! Christian Perle -- Christian Perle Senior Berater / Senior Consultant Netzwerk- und Client-Sicherheit / Network & Client Security Öffentliche Auftraggeber / Public Authorities secunet Security Networks AG Tel.: +49 201 54 54-3533, Fax: +49 201 54 54-1323 E-Mail: christian.perle@secunet.com Ammonstraße 74, 01067 Dresden, Deutschland www.secunet.com secunet Security Networks AG Sitz: Kurfürstenstraße 58, 45138 Essen, Deutschland Amtsgericht Essen HRB 13615 Vorstand: Axel Deininger (Vors.), Torsten Henn, Dr. Kai Martius, Thomas Pleines Aufsichtsratsvorsitzender: Ralf Wintergerst
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index 89fff5f59eea..2ed0b01f72f0 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -302,7 +302,7 @@ static int __ip_finish_output(struct net *net, struct sock *sk, struct sk_buff * if (skb_is_gso(skb)) return ip_finish_output_gso(net, sk, skb, mtu); - if (skb->len > mtu || (IPCB(skb)->flags & IPSKB_FRAG_PMTU)) + if (skb->len > mtu || IPCB(skb)->frag_max_size) return ip_fragment(net, sk, skb, mtu, ip_finish_output2); return ip_finish_output2(net, sk, skb);
Conntrack reassembly records the largest fragment size seen in IPCB. However, when this gets forwarded/transmitted, fragmentation will only be forced if one of the fragmented packets had the DF bit set. In that case, a flag in IPCB will force fragmentation even if the MTU is large enough. This should work fine, but this breaks with ip tunnels. Consider client that sends a UDP datagram of size X to another host. The client fragments the datagram, so two packets, of size y and z, are sent. DF bit is not set on any of these packets. Middlebox netfilter reassembles those packets back to single size-X packet, before routing decision. packet-size-vs-mtu checks in ip_forward are irrelevant, because DF bit isn't set. At output time, ip refragmentation is skipped as well because x is still smaller than the mtu of the output device. If ttransmit device is an ip tunnel, the packet size increases to x+overhead. Also, tunnel might be configured to force DF bit on outer header. In this case, packet will be dropped (exceeds MTU) and an ICMP error is generated back to sender. But sender already respects the announced MTU, all the packets that it sent did fit the announced mtu. Force refragmentation as per original sizes unconditionally so ip tunnel will encapsulate the fragments instead. The only other solution I see is to place ip refragmentation in the ip_tunnel code to handle this case. Fixes: d6b915e29f4ad ("ip_fragment: don't forward defragmented DF packet") Reported-by: Christian Perle <christian.perle@secunet.com> Signed-off-by: Florian Westphal <fw@strlen.de> --- net/ipv4/ip_output.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)