netdev - Re: Fix FRTO+NewReno problem (Was: Re: This has a work around)

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.0805121935440.13395@wrl-59.cs.helsinki.fi>
Date:	Mon, 12 May 2008 19:40:29 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	"Damon L. Chesser" <damon@...tek.com>
cc:	Netdev <netdev@...r.kernel.org>
Subject: Re: Fix FRTO+NewReno problem (Was: Re: This has a work around)

On Mon, 12 May 2008, Ilpo Järvinen wrote:

> On the bright side, the FRTO problem that was occuring previously is now fixed
> but there seems to be very few ways to communicate with that device sanely
> because it assumes in-order arrival and keeps discarding, as it seems, _all_
> other segments... If you could try with this additional work-around attached
> (keep the fixes there as well). Turn tcp_frto_inorder_workaround sysctl to 1
> before testing with FRTO.

I missed one thing with the last workaround patch, please use this one 
instead if you haven't yet have time to try it.

-- 
 i.
View attachment "0001-TCP-FRTO-workaround-in-order-only-receivers.patch" of type "TEXT/PLAIN" (3378 bytes)