netdev - Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround

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.0808162210390.7443@wrl-59.cs.helsinki.fi>
Date:	Sat, 16 Aug 2008 22:18:50 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	"Dâniel Fraga" <fragabr@...il.com>
cc:	David Miller <davem@...emloft.net>, thomas.jarosch@...ra2net.com,
	billfink@...dspring.com, Netdev <netdev@...r.kernel.org>,
	Patrick Hardy <kaber@...sh.net>, sr@...urenet.de,
	netfilter-devel@...r.kernel.org, kadlec@...ckhole.kfki.hu
Subject: Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround

On Sat, 16 Aug 2008, Ilpo Järvinen wrote:

> On Fri, 15 Aug 2008, Dâniel Fraga wrote:
> 
> > with mail or nntp, interesting no?). All the other services (http,
> > ssh, ftp always work fine).
> >
> > 	But the file is small. I don't know if it will help.
> > 
> > 	If not, no problem, just tell me and I'll try harder next time.
> 
> This seems to be a valid sample, thanks. I'll return once I have figured 
> something out (it might be that our state machine is somehow broken since 
> there's traffic in both ways (rexmitted), yet neither party seems to be 
> very willing to make progress).

Some thoughts, nothing very earth-shattering yet...

It seems that the server (port 995) never leaves SYN-RECV state because it 
keeps retransmitting SYNACKs. While the other end (the client) is doing 
it's best to ACK them (correctly) and it also tries to send some data 
which never gets through and retransmissions are attempted for it (those 
packets also contain a ACK seqno that should be enough to end the 
SYN-RECV but for some reason that never happens). Eventually the 
connection is RSTed.

I'll look through 2.6.24..25 history once I have some time to see if 
there are some clues about the cause. I'm also having a problem in 
figurin out why would the frto patch you tested solve this issue (unless 
there are two issues in the picture).

-- 
 i.