• Skip to primary navigation
  • Skip to main content

Inodes

Fractional CTO Consulting

  • Home
  • About Us
  • Contact Us
  • Block Examples
  • Landing Page
  • Pricing Page
  • Show Search
Hide Search

TCP Window Scaling and kernel 2.6.17+

John Ferlito · 6 September 2006 · 13 Comments

So I was tearing my hair out today. I’d installed Ubuntu onto a new Sun X4200 so that I could migrate Bulletproof’s monitoring system to it. (Note you need to use edgy knot-1 for the SAS drives to be supported). Anyway as I was installing packages I was getting speeds like 10kB/s. Normally I would expect 800-1000kB/s.

I did the usual sort of debugging, where there any errors on the switch, was it affecting other servers on the same network etc etc. Everything looked fine. Our friend tcpdump showed a dump that looked something like this.

root@oldlace:~# tcpdump -ni bond0 port 80
tcpdump: listening on bond0
1.2.3.4.42501 > 203.16.234.85.80: S 0:0 win 5840 <mss 1460,sackOK,timestamp 94318 0,nop,wscale 6> (DF)
203.16.234.85.80 > 1.2.3.4.42501: S 0:0(0) ack 1 win 5840<mss 1460,nop,wscale 2> (DF)
1.2.3.4.42501 > 203.16.234.85.80: . ack 1 win 92 (DF)
1.2.3.4.42501 > 203.16.234.85.80: P 1:352(351) ack 1 win 92 (DF)
203.16.234.85.80 > 1.2.3.4.42501: . ack 352 win 1608 (DF)

You’ll notice that the server initially advertises a window size of 5840, then suddenly in the first ACK it is advertising a size of 92. This means that the other side can only send 92 bytes before waiting for an ACK!!! Not very conducive to quick WAN transfer speeds.

After a lot of Google searching I discovered these threads on LKLM

  • http://www.gatago.com/linux/kernel/9440712.html
  • http://lwn.net/Articles/92727/
  • http://oss.sgi.com/archives/netdev/2004-07/msg00142.html

Of course what I was missing was the wscale 6, which means that the windows was actually 92*2^6 = 5888. Which is pretty close to 5840 so why bother with the scaling, because towards the end of the connection we get 16022*2^6 = 1025408 which doesn’t normally fit into a TCP header.

So why aren’t things screaming along with this massive window, well something in the middle doesn’t like a windows scaling factor of 6 and is resetting it to zero. Which means the other end thinks the windows size really is 92.

There are 2 quick fixes. First you can simply turn off windows scaling all together by doing

Bash
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

but that limits your window to 64k. Or you can limit the size of your TCP buffers back to pre 2.6.17 kernel values which means a wscale value of about 2 is used which is acceptable to most broken routers.

Bash
echo "4096    16384   131072" > /proc/sys/net/ipv4/tcp_wmem
echo "4096    87380   174760" > /proc/sys/net/ipv4/tcp_rmem

The original values would have had 4MB in the last column above which is what was allowing these massive windows.

In a thread somewhere which I can’t find anymore Dave Miller had a great quote along the lines of

“I refuse to workaround it, window scaling has been part of the protocol since 1999, deal with it.”

Sysadmin Bulletproof, kernel, linux, tcpdump

Reader Interactions

Comments

  1. MC says

    6 September 2006 at 11:18 pm

    Your refrence links are broken.

    Reply
  2. johnf says

    7 September 2006 at 8:16 am

    Thanks, fixed now.

    Reply
  3. GNEMAN says

    28 September 2006 at 2:11 pm

    The argument that they shouldn’t workaround the window scaling problem because there shouldn’t be broken boxes out there in the first place is just like saying that we shouldn’t have jails becasue people shouldn’t be doing illegal things in the first place. Yes, in an ideal world that’s correct. But we don’t live in an ideal world. People do illegal things, so we need jails. And there are broken boxes out there, so we need workarounds. The day no one does any illegal thing will be the day to get rid of jails, not before. And the day there are no broken boxes out there, we can use this new window scaling value. It’s simple. Now when most big distros move to kernel 2.6.17 (just in the next month or 2) we’ll have thousands of people complaining that their connection doesn’t work. And nobody will know or care about window scaling. They’ll just want their computer to work as it did before.

    Oops, sorry for the rant. It’s not aimed at you, of course. I just thought I would post my thoughts about this issue here in case Linux Torvalds reads this blog 🙂

    Reply
  4. Murray says

    23 November 2006 at 3:53 pm

    Another way…

    vi /etc/sysctl.conf

    add the following two lines

    net.ipv4.tcp_wmem = 4096 16384 131072
    net.ipv4.tcp_rmem = 4096 87380 174760

    sysctl -p

    Reply
  5. sathish says

    13 August 2007 at 2:52 pm

    How to turn off windows scaling on windows xp pc

    Reply
  6. chouse says

    31 January 2008 at 6:47 am

    Totally solved my issue with RHEL5. Big thanks.

    Reply
  7. Dao-Chen Zheng says

    20 May 2009 at 4:25 am

    On Linux, is there a way to increase the TCP window size in the TCP header to a larger value than 0x16d0 (5840)?

    I would like to keep TCP window size more or less unchanged at 5840*128 by increasing “16 D0” to something like “FF FF” and reducing the Window Scaling Factor to a smaller value than 128.

    Basically, I am trying to find a workaround for the web sites that have the bug of ignoring TCP window scaling without having an impact on other web sites.

    Thanks.

    Reply
  8. blingo says

    1 October 2009 at 6:16 pm

    Thanks a lot, until reading this I was using old kernels to resolve this..

    Reply

Trackbacks

  1. The Adventures of Slightly Taller Than Average Man » Fedora kernel upgrade caused excruciatingly slow network speeds says:
    5 March 2007 at 7:20 pm

    […] Googling found nothing, so I had to grin and bear it until the sysadmin found a fix.  After a while, he came across this solution (from here). echo 0 > /proc/sys/net/ipv4/tcp_window_scaling […]

    Reply
  2. infotage.net » Blog Archive » Debian ip stack tuning says:
    17 March 2007 at 11:58 am

    […] http://inodes.org/blog/2006/09/06/tcp-window-scaling-and-kernel-2617/ […]

    Reply
  3. bizarre lack of HTTP response problem - Page 2 - Linux Forums says:
    29 June 2007 at 4:58 pm

    […] explanation / workaround Recently I found out what is going on with this bug. The problem has to do with larger default buffer sizes for TCP window scaling in recent Linux kernel versions. If there is an improperly configured router between you and the server you’re trying to reach, it will create a bottleneck and you’ll get no data from the server. The long and the short of it is that it is not a Linux bug. Here are some better, more detailed explanations: John

    Reply
  4. Grant Carmichael » Blog Archive » Is your Linux box running slow behind your firewall? says:
    1 February 2008 at 5:47 am

    […] First read the following articles: […]

    Reply
  5. linsec.ca blog » Blog Archive » Welcome back, kernel 2.6.17+ says:
    26 March 2008 at 5:18 am

    […] Due to an issue that the 2.6.17+ kernel exemplified, all of the sites I host (annvix.org, linsec.ca, danen.ca, etc.) have been unavailable to anyone using a 2.6.17+ kernel due to a change in the way TCP window scaling was implemented, which has been noted in a number of places (here’s one: TCP Window Scaling and kernel 2.6.17+). […]

    Reply

Leave a Reply to bizarre lack of HTTP response problem - Page 2 - Linux Forums Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Hit the ground running with a minimalist look. Learn More

Copyright © 2025 · Inodes Pty Ltd · Log in

  • Privacy Policy