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

On Mon, 12 May 2008, Damon L. Chesser wrote:

> I applied the patches in order, no errors on that.  I compiled a stock
> 2.4.24-1 kernel with the patches, I saw no errors there.
> 
> booted into new kernel, printed with tcp_frto=0.  set tcp_frto =2, restarted
> the network (is this required, or is this a dynamic setting?), printed from OO
> document.  No joy.  tcpdump log attached (almost 15 min. worth of data)
> 
> If you want, I can re-compile and double check for any compilation errors,
> however, if there were any, it was not sever enough to stop the compilation.

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.

...Can you please send a dump about working case too, this seems rather 
nasty device to work with (tcp_frto = 0 is enough to attain it, no 
need to have another kernel booted for that) and I'm interested to see 
what are the loss rates without FRTO...

-- 
 i.
View attachment "0001-TCP-FRTO-workaround-in-order-only-receivers.patch" of type "text/plain" (3017 bytes)