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]
Message-ID: <20060818200323.40b1a74a@localhost.localdomain>
Date:	Fri, 18 Aug 2006 20:03:23 -0700
From:	Stephen Hemminger <shemminger@...l.org>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tcp: limit window scaling if window is clamped

On Fri, 18 Aug 2006 17:00:30 -0700 (PDT)
David Miller <davem@...emloft.net> wrote:

> From: Stephen Hemminger <shemminger@...l.org>
> Date: Fri, 18 Aug 2006 10:29:38 -0700
> 
> > This small change allows for easy per-route workarounds for broken hosts or
> > middleboxes that are not compliant with TCP standards for window scaling.
> > Rather than having to turn off window scaling globally. This patch allows
> > reducing or disabling window scaling if window clamp is present.
> > 
> > Example: Mark Lord reported a problem with 2.6.17 kernel being unable to
> > access http://www.everymac.com
> > 
> > # ip route add 216.145.246.23/32 via 10.8.0.1 window 65535
> > 
> > I would argue this ought to go in stable kernel as well.
> > 
> > Signed-off-by: Stephen Hemminger <shemminger@...l.org>
> 
> I want to think about this some more, it might have unintended
> consequences.  I really am not all that thrilled about putting in
> workaround for this problem especially if it hurts a legitimate use of
> some kind.

I was going for the least impact workaround using existing mechanisms.
There already is a way to set metrics per route. The code already limits
the window scale to the maximum possible window based on tcp memory limit
so it made sense to clamp based on congestion window as well.
It didn't make sense to add a new metric.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ