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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 8 May 2008 23:42:21 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	"Damon L. Chesser" <damon@...tek.com>
cc:	Bug 213081 <213081@...s.launchpad.net>, 478062@...s.debian.org,
	Netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: Fix FRTO+NewReno problem (Was: Re: This has a work around)

On Thu, 8 May 2008, Damon L. Chesser wrote:

> Ilpo Järvinen wrote:
> > SNIP
> 
> >
> > Could you next try with tcp_frto set to 1, if my theory proves to be
> > correct, it too should be "enough" to fix the problem (in this particular
> > case). Of course you can verify the patch below too if you want to, the
> > patch should allow cups<->printer to work with tcp_frto = 2 too. In case you
> > have problem to apply the patch to the particular version you're want to try
> > with, just send a note about the version number to me so I can adapt the
> > patch for you (space etc. formatting issues may show up because I recently
> > run a code style cleanup on the tcp code).
>
> reran the print job with the correct kernel (for control reasons) and received
> the same results:  tcp_frto=1 no print.  tcp_frto=0 I can print.  Attached is
> the output of tcpdump
> 
> uname -r = 2.6.24-1-amd64

Well, that was a surprise, there must be something else too I didn't yet 
notice. I don't think it's that necessary for you to test that patch I 
sent earlier (basically the code paths it would have fixed were already in 
use with tcp_frto=1). And that patch was "obviously correct" anyway though 
it wasn't enough to fix this issue.

...I too can probably reproduce this locally with small amount of work 
because the receiver pattern is dead obvious from the logs.

-- 
 i.