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, 23 Aug 2008 00:18:44 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Thomas Jarosch <thomas.jarosch@...ra2net.com>
cc:	David Miller <davem@...emloft.net>, billfink@...dspring.com,
	fragabr@...il.com, Netdev <netdev@...r.kernel.org>,
	Patrick Hardy <kaber@...sh.net>,
	netfilter-devel@...r.kernel.org, kadlec@...ckhole.kfki.hu
Subject: Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround

On Tue, 12 Aug 2008, Thomas Jarosch wrote:

> On Monday, 11. August 2008 23:44:21 David Miller wrote:
> > Trying to come up with a signature for this bogus stuff is both time
> > consuming and having a risk of false positives.  And I really question
> > whether this thing is worth it.
> >
> > The sane thing to do in this case is to declare the box inoperative
> > and that it needs to be fixed to avoid this behavior.
> >
> > Any reasonable congestion control scheme is going to run into problems
> > trying to react to the packet patterns this thing creates.  It is
> > therefore not really limited to FRTO so it really shouldn't be treated
> > like an FRTO problem even though it shows up more pronounced when
> > FRTO is enabled.
> 
> David, I agree with you, though I'm not sure about the end user experience:
> 
> The kernel is an early adopter of FRTO and will be bitten by bugs of other
> TCP implementations like we've experienced. I guess most affected users
> just see stalled or slow connections and won't have the time or knowledge
> to debug this.

This is hardly a big problem. Much bigger problem seems to be that some 
distros base to 2.6.24 and did not take TCP fixes that were put to 
2.6.25.7 but not to 2.6.24.y series because it wasn't updated anymore. 
There are hardly any other reports but for 2.6.24 (and the ones which we 
have have gone through @ netdev to fix the bugs / problems) in the ones 
I've seen.

> A proper warning could help them and the kernel
> developers to get this issue solved as quickly as possible.
> 
> We called the hotline of the ISP several times and they always claimed
> sending big mails with Outlook/Windows works, so it must be linux's fault.
> That view of things is totally biased, but it's something I want to make sure
> people can't get away with easily :-)

I should probably one day check how vista's frto is behaving
itself to know better... ...but I guess they'll be running to
some problems with big mails pretty soon... ;-)

In the meantime, can you check the attached patches. Besides the kernel 
patch, you need to build your own patched iproute2 as well to configure 
the features (ip tool among them is enough in case the build of some other 
part of the toolset fails like it did for me). I somewhat tested them, and 
the result seemed to be what I'd expect (I just forced RTOs with some 
netem heavy dropping and quickly glanced over the resulting packet 
patterns near RTO).

-- 
 i.

View attachment "0001-tcp-frto-make-frto-per-route-configurable.patch" of type "text/plain" (1764 bytes)

View attachment "0001-iproute2-enable-setting-of-per-route-features.patch" of type "text/plain" (5146 bytes)