netdev - Re: TCP connection stalls under 2.6.24.7

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: <Pine.LNX.4.64.0807190950001.10828@wrl-59.cs.helsinki.fi>
Date:	Sat, 19 Jul 2008 10:35:38 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Thomas Jarosch <thomas.jarosch@...ra2net.com>
cc:	Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>,
	Netdev <netdev@...r.kernel.org>,
	Patrick McHardy <kaber@...sh.net>,
	Sven Riedel <sr@...urenet.de>,
	Netfilter Developer Mailing List 
	<netfilter-devel@...r.kernel.org>,
	"Dâniel Fraga" <fragabr@...il.com>,
	David Miller <davem@...emloft.net>
Subject: Re: TCP connection stalls under 2.6.24.7

On Fri, 18 Jul 2008, Thomas Jarosch wrote:

> On Friday, 18. July 2008 15:55:22 Ilpo Järvinen wrote:
> > Btw, on which kernel you ran these things (I hope it wasn't 2.6.24.7,
> > which has FRTO related bugs anyway that the patches I've sent now won't
> > fix)?
> 
> It's the git "master" tree from two days ago, so it should be 2.6.27-pre.
> Like I wrote before, there's another box doing NAT in front of it running 
> 2.6.24.7. FRTO is disabled on that box. Hope that helps a bit.

Hmm, those were spurious RTOs indeed or a sign of perverted TCP "proxy" 
(or whatever they call them), longest delay spike I've found so far is 
this:

11:27:28.454827 172.16.1.131.56060 > 80.152.31.131.25: . 3989187:3990587(1400)
...
11:28:00.188835 80.152.31.131.25 > 172.16.1.131.56060: . ack 3990587 win 65535

That's 32 seconds? :-D What should TCP do with that :-) ...disregard that 
measurement because some other TCP variant would not be able to use the 
same measurement due to ambiguity problem(?), I don't think so... It seems
that non-FRTO TCP just misses those signs and acts _too_ aggressively ;-),
which is well known to happen when spurious RTO occurs.

...Also, those duplicate ACKs I pointed out earlier are a sign of 
unnecessary retransmissions (they occur both with and without FRTO).
I actually doubt you have any real losses there, I'll probably next 
calculate RTTs based on that assumption in the non-FRTO dump too...

-- 
 i.