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] [day] [month] [year] [list]

Date:	Tue, 26 Aug 2008 15:03:38 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Thomas Jarosch <thomas.jarosch@...ra2net.com>
cc:	Netdev <netdev@...r.kernel.org>, netfilter-devel@...r.kernel.org
Subject: Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround

On Mon, 25 Aug 2008, Thomas Jarosch wrote:

> On Friday, 22. August 2008 23:18:44 Ilpo Järvinen wrote:
> > 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).
> 
> Your patches work fine.

Thanks for testing.

> I've noticed two small things:
> 1. Maybe it's a good idea to add a note above the tcp_use_frto() change
> to explain that the value is negated. Took me a while to figure out
> why there is no "!" in there :-)
> 2. Maybe rename the "features" option in iproute2 to "disable_features".
> Then it would be more intuitive what it does.

First of all I hate doing anything which has an user interface stamp in 
it... :-)

Second, didn't I write about this negation in some of the log messages... 
/me looks for that... hmm... I think I did ...and that's besides the very 
clear help text :-). 

Yeah, it was just that the earlier ip already prints the field as 
"features" though I guess changing also that is a non-problem to existing 
userspace stuff because of the current usage of the field. There's this 
RTAX_FEATURE_ALLFRAG stuff which somebody could be looking for but I 
don't know how likely that will be.

But anyway, point taken. I'll try to change both to disable_features and 
see if that gets accepted.

-- 
 i.