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]

Date:	Thu, 7 Aug 2008 15:14:08 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Denys Fedoryshchenko <denys@...p.net.lb>
cc:	"Dâniel Fraga" <fragabr@...il.com>,
	Thomas Jarosch <thomas.jarosch@...ra2net.com>,
	Netdev <netdev@...r.kernel.org>,
	Patrick McHardy <kaber@...sh.net>,
	Sven Riedel <sr@...urenet.de>,
	Netfilter Developer Mailing List 
	<netfilter-devel@...r.kernel.org>,
	Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>,
	David Miller <davem@...emloft.net>
Subject: Re: TCP connection stalls under 2.6.24.7

On Thu, 7 Aug 2008, Denys Fedoryshchenko wrote:

> On Thursday 07 August 2008, Ilpo Järvinen wrote:
> > On Wed, 6 Aug 2008, Dâniel Fraga wrote:
> > > On Thu, 31 Jul 2008 15:47:55 +0200
> > >
> > > Thomas Jarosch <thomas.jarosch@...ra2net.com> wrote:
> > > > If your problem is really FRTO related (that what the patch is for),
> > > > you could try to disable FRTO temporarily:
> > >
> > > 	Hi, the patch helped, but what's the conclusion? Is the problem
> > > "solved"? Will this patch be merged in the next kernel? This thread
> > > seems to be forgotten.
> >
> > I was yesterday preparing the patch description by adding some more
> > thoughts to it (as if there weren't enough already) but didn't yet send it
> > with new cover (to sort of notify davem).
> >
> > I give no guarantees about the _next_ kernel but some 2.6.26.y and 2.6.27
> > is more likely bet.
> 
> By the way, i had also problem with frto with local connections, and it was 
> trivial to reproduce. But because of proprioetary(but i have sources) 
> userspace application and specific way of using it - i didn't report to 
> maillist.

I could have still looked to it :-), I can mostly decide anything TCP 
congestion control related based on solely a tcpdump, and I can even read 
tcpdump -n -r logfile output if you want to fully hide any payloads (as 
long as the lines are not split to a mess in an email :-)) though then 
plotting them is not as easy for me (I could hack my tool someday though 
to handle that as well).

But if there is pre-2.6.25.7/2.6.26 kernel involved, then it's obsolete 
one and requires upgrade or the relevant fixes from 2.6.25.7.

> But after patch is ready, add me please in cc, i will test it with 
> me too.

I already sent it, though vger was in some sort of distress, so it might 
take some time to arrive...

> For me disabling frto helps to solve problem. With frto i have 
> connections "stalling", if there is trasferred large chunks of data over 
> loopback. It is complicated way how it works all - but i can try to explain 
> how everything works, if required.

Could you just tcpdump over (at least) one stall? ...That would be useful 
even if you find the patch I sent working because it's always possible 
that something has been overlooked in FRTO spec or so and I would like to 
understand the problem rather than just use a workaround which was 
intented to fix (possibly) other problem...

If there's something I cannot figure out from the dump, I'll then consult 
you about the userspace details.

-- 
 i.