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: <48288EFE.4020708@damtek.com>
Date:	Mon, 12 May 2008 14:39:58 -0400
From:	"Damon L. Chesser" <damon@...tek.com>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
CC:	Netdev <netdev@...r.kernel.org>, David Miller <davem@...emloft.net>
Subject: Re: Fix FRTO+NewReno problem (Was: Re: This has a work around)

Ilpo Järvinen wrote:
> 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...
>
>
New patch added in with the first two, tcp_frto_inorder_workaround =1 
test printed 5 pages:  This worked.  Attached is the output of tcpdump.  
Need anything else?

-- 
Damon L. Chesser
damon@...tek.com
http://www.linkedin.com/in/dchesser


Download attachment "frtoprob6.txt.gz" of type "application/x-gzip" (235644 bytes)