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]

Date:	Fri, 12 Dec 2014 21:31:41 +0100
From:	Wolfgang Walter <linux@...m.de>
To:	Eric Dumazet <eric.dumazet@...il.com>
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.

Am Freitag, 12. Dezember 2014, 09:27:05 schrieb Eric Dumazet:
> On Fri, 2014-12-12 at 17:58 +0100, Wolfgang Walter wrote:
> > This fixes hangs of local tcp connections over ipsec tunnels where
> > pmtu is lower than the mtu of the interface.
> 
> Again this is a work around, the one liner patch is not a clean patch.
> 
> Something is wrong, we should fix GSO path instead.
> 
> Why ? Because we can queue a GSO packet in a qdisc, then later call
> sk_setup_caps() (too late)

Hmm. Do you think that sk_setup_caps should not disable GSO later at all? Or 
only that it should not influence already queued packets?

In the case of an ipsec tunnel GSO gets disabled later (for tcp connections) 
because dst->header_len() is zero at first and non-zero later. tcp connections 
initiated not to long afterwards start with GSO disabled from the beginning.

dst->header_len() being non zero for ipsec tunnels seems to be the case with 
or without an adjustment via PMTU. It seems that routing only does not know it 
from the beginning on (for incomimg connections) :-).

Why does a non zero dst->header_len() disable GSO? Is it just an optimization 
or does GSO not work in that case? If dst->header_len() being non zero signals 
that ipsec tunnel mode can't handle GSO at all then the problem would not lay 
in the gso path.

There is one thing which indicates that there is also a problen in the GSO 
path, though. As my tests demonstrated disabling GSO on the physical interface 
serving the ipsec tunnel does not prevent the hangs. It does, though, if sk-
>sk_gso_max_segs = 1 in sk_setup_caps() if sk_can_gso(sk) returns false. This 
was the first variation of the patch where sk->sk_gso_max_segs was not set if 
dst->header_len() is non zero.

Concering qdisc: an ipsec tunnel doesn't have a "tunnel-device" so it does not 
have qdisc? The ipsec tunnel transforms packets and the results are (in case 
of ipsec esp tunnel) esp packets which cannot be resgmented. Only these 
transformed packets are finally queued to a qdisc of a network device then.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--
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