netdev - Re: [bisected] xfrm: TCP connection initiating PMTU discovery stalls on v3.

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: <1418161219.27198.10.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Tue, 09 Dec 2014 13:40:19 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Wolfgang Walter <linux@...m.de>
Cc:	Thomas Jarosch <thomas.jarosch@...ra2net.com>,
	netdev@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Steffen Klassert <steffen.klassert@...unet.com>
Subject: Re: [bisected] xfrm: TCP connection initiating PMTU discovery
 stalls on v3.

On Tue, 2014-12-09 at 21:36 +0100, Wolfgang Walter wrote:

> How would that be done? I found no way to disable it especially for xfrm. I 
> disabled gso for the interface which serves the ipsec traffic but this does 
> not help. tcp still uses gso for the esp tunnel.
> 
> I put a view printk's in net/xfrm/xfrm_output.c and net/ipv4/tcp_output.c. (I 
> try to understand where in the xfrm transformation gso is handeled).
> 
> What I can say yet is:
> 
> xfrm_output() is used with ipsec (esp) tunnel mode but at I never see gso 
> packets here. xfrm_output_gso() is never called.
> 
> Everytime tcp_set_skb_tso_segs() is called for a tcp connection over the esp-
> tunnel and it is a gso case then the tcp connection hangs. Those packets 
> always have skb->len 1398 and mss_now is 1374. I see a call of xfrm_output() 
> afterwards but for a packet of skb->len 52 (maybe ACK from other direction?).
> 
> As long as the tcp-connection over the ipsec-tunnel works and if I send bulk 
> traffic xfrm_output() is called 3 times with packet skb->len 1426 and then one 
> time with 78 (maybe other direction?), don't know if that is of any interest.
> 
> 
> With non-ipsec-traffic gso works fine: in this case the skb->len() varies a 
> lot and mss_now is always 1288.
> 

Presumably something happens so that sk_can_gso() returns false.

But apparently, this happens _after_ tcp_sendmsg(), ie a bit too late.

Note that after https://patchwork.ozlabs.org/patch/418506/ is applied,
fix would simply be :

diff --git a/net/core/sock.c b/net/core/sock.c
index 9a56b2000c3f374fb95aedada3327447816a9512..678ef8393680dc781445c5f121719ea8ea7bb7c1 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1585,6 +1585,8 @@ void sk_setup_caps(struct sock *sk, struct dst_entry *dst)
 			sk->sk_gso_max_size = dst->dev->gso_max_size;
 			sk->sk_gso_max_segs = dst->dev->gso_max_segs;
 		}
+	} else {
+		sk->sk_gso_max_segs = 1;
 	}
 }
 EXPORT_SYMBOL_GPL(sk_setup_caps);


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html