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]

Date:	Sat, 16 Aug 2008 10:10:27 +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 Fri, 15 Aug 2008, Dâniel Fraga wrote:

> On Sat, 16 Aug 2008 01:06:55 +0300 (EEST)
> "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> wrote:
> 
> > Ok. I hope it will still reproduce with tcpdump running... Btw, doing cat 
> > /proc/net/tcp during the stall wouldn't be a bad idea (in addition to 
> > tcpdumping it). Also please let the tcpdumps run long enough if the stall 
> > persists, something like 15mins doesn't hurt because there are large 
> > timer values possibly involved.
> 
> 	Hi, I did the following:
> 
> fraga@tux ~/src$ cat /proc/net/tcp 

...snip...

> 	And I can't use host and port at the same time with tcpdump (or
> I did something wrong) so I used (I need to update this, can't find
> the manpage... I tried to download a newer version but the link form
> the site seems broken):
> 
> sudo tcpdump -w dump-mail.log -i eth0 port 995

Hmm, sudo /usr/sbin/tcpdump -i eth1 host 192.168.1.1 and port 22 works for 
me, perhaps you forgot the and-operator in between them? Anyway, it seems 
quite fine.

> 	to capture mail traffic that was stuck (usually it only happens
> with mail or nntp, interesting no?). All the other services (http,
> ssh, ftp always work fine).
> 
> http://www.abusar.org/dump-mail.log
> 
> 	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.
> Thanks.

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).

-- 
 i.