[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#407735: 2.6.18-3-686 tcp_window_scaling serious problem



I found one other site discussing this issue and how/why it is a
political issue related to the Linux kernel:

http://groups.apu.edu/awg/node/101


"The recent 2.6.8 kernels have enabled TCP Window Scaling by
default...."

"So why doesn't it work with Linux? Well the problem is not with Linux
at all, other than the fact that they turned it on by default.
Apparently many routers and packet firewalls are rewriting the window
scaling factor during a transmission, instead of only during the initial
handshake (SYN). This means that the sending and receiving side are
assuming a different TCP window size. The result of this misnegotiation
of protocol, is very slow successful traffic if at all."

"The solution? Well, some of the linux developers are hoping that
leaving the option enabled will force the issue, so that vendors will
fix their routers."

http://lkml.org/lkml/2004/7/6/90





So wrote prosolutions@gmx.net on Sunday, 21 January 2007:
> Date: Sun, 21 Jan 2007 10:08:59 -0800
> From: prosolutions@gmx.net
> To: Bastian Blank <waldi@debian.org>
> Subject: Re: Bug#407735: 2.6.18-3-686 tcp_window_scaling serious problem
> User-Agent: Mutt/1.5.13 (2006-08-11)
> Cc: prosolutions@gmx.net, 407735@bugs.debian.org
> 
> > 
> > tags 407735 wontfix
> > severity 407735 minor
> > thanks
> > 
> 
> I've been googling about this problem.  It could be a problem with the
> way many routers around the world are configured, yet only manifests
> with particular Linux kernel versions.  It may be that many network
> admins need to change their configuration, but this would be a political
> issue, not something end-users should be forced to bear the brunt of.
> 
> Once again, this problem has nothing to do with my local hardware, and
> occurs consistently with the same exact sites on the Internet (one
> example: slashdot.org).  Doing  echo "0" >
> /proc/sys/net/ipv4/tcp_window_scaling  fixes the issue completely.
> 
> 
> 
> http://en.opensuse.org/SDB:Problem_with_establishing_TCP/IP_connection_in_openSUSE_10.2
> 
> http://www.mail-archive.com/debian-doc@lists.debian.org/msg09314.html
> 
> http://www.penlug.org/twiki/bin/view/Main/CiscoVpn
> 
> "The recent 2.6.7 kernel's TCP changes are only exposing a pre-existing
> problem with a large number of poor/broken firewall implementations.
> These are clueless firewall implementations that strip or alter the TCP
> options. When the options are modified, TCP gets busted. The reason this
> matters now, is that when the linux kernel proposes a new window
> scaling, it quite sensibly expects that the other side will receive the
> same initial SYN request that it actually sent. If there is a clueless
> firewall in the middle that corrupts or strips it, then the window we
> send is not correctly scaled, and the result is that the other side
> thinks that there is not really enough space to send. The current
> proliferation of these clueless firewall implementations resulted in a
> proposal on the linux kernel mailing list by Stephen Hemminger, where he
> proposes a patch that will avoid sending window scaling that is big
> enough to break in these cases unless the tcp_rmem has already been
> increased. The aim is to keep the default configuration from blowing in
> a corrupt world. For more details on the lively ensuing discussion of
> Stephen's patch, search for the following string in the archive pages
> listed below: 
> 
>   "[PATCH] fix tcp_default_win_scale." 
> 
>   See the Jul 1 to Jul 7, 2004 lkml archives. Also the Jul 8 to Jul 15,
>   2004 lkml archives 
> 
>   There's also an entertaining explanation from James Janssen, a Gentoo
>   user, here.
> "
> 
> 




Reply to: