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.0808150939270.23522@wrl-59.cs.helsinki.fi>
Date:	Fri, 15 Aug 2008 10:06:39 +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 Wed, 13 Aug 2008 21:34:10 +0300 (EEST)
> "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> wrote:
> 
> > Ok, thanks for your efforts... These are often hard to reproduce because
> > some not that likely pattern needs to happen and such things is often not
> > easily controllable (if it is at all possible to influence the 
> > likelyhoods).
> 
> 	Hi Ilpo, I don't know if the dumps are correct, but I did when
> the connection was stalled.

I would be better to have tcpdump running at least a bit back (2-3 windows 
back is long enough for me), but obviously that might not be possible 
option because it occurs so rarely. ...It should be possible to have 
tcpdump restarted once in a while to avoid a one huge log if you'd just 
keep running tcpdump from beginning.

> The problem is, when I dumped "eth0", the connection suddenly come back 
> alive again...

The situation (or some of those I did debug with other people) are such 
that they may indeed resolve themself, though I'm also interested why the 
slow part occurred.

> so, I don't know if it's useless or not:

What do you mean by "come back alive"...? ...In eth0 log I found this 
connection 189.38.18.122.995 > 192.168.0.2.35477, the ip matches with 
abusar's. But I'm not sure if the connection in the tunnel is the 
interesting one, since it's going to/from port 119 but the ip addresses 
(10.195.195.2 and 10.195.195.1) don't tell anything to me, I guess you 
know their meaning (ie., if 10.195.195.2 is the one with which the 
connection stalls)? ...You're probably right that this wasn't very useful 
log, the longest "stall" I find is only 1.111328 seconds long (and it 
might be due to some processing that is made by 10.195.195.2).

-- 
 i.