Bug 126626 - network connection problem with 2.6.7-1.441 and up
network connection problem with 2.6.7-1.441 and up
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Depends On:
  Show dependency treegraph
Reported: 2004-06-23 18:03 EDT by Gary Peck
Modified: 2015-01-04 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-05 20:01:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
tcpdump of successfull connection with kernel-2.6.6-1.427 (2.31 KB, text/plain)
2004-06-23 18:14 EDT, Gary Peck
no flags Details
tcpdump of unsuccessfull connection with kernel-2.6.7-1.441 (1.25 KB, text/plain)
2004-06-23 18:15 EDT, Gary Peck
no flags Details

  None (edit)
Description Gary Peck 2004-06-23 18:03:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040612 Firefox/0.8

Description of problem:
I've been experiencing a weird network problem ever since upgrading to
kernel-2.6.7-1.441. Connecting to pretty much every known web site
works fine, with the exception of my own server at
http://realify.com/. Others can connect to realify.com with no
problems, and I can ping realify.com successfully. But HTTP, IMAP,
etc. connections all hang.
Downgrading to kernel-2.6.6-1.427 fixes the problem. The new
2.6.7-1.448 kernel does not.                                         

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Open Mozilla/Firefox.
2. Type in "http://realify.com/" into the address bar.

Actual Results:  The browser throbber keeps spinning and the browser's
status bar says "Waiting for realify.com...".

Expected Results:  The web site should load fine.

Additional info:

In case this is helpful, I've attached the output of tcpdump
(reformatted for readability) while trying to connect to
http://realify.com/ from Firefox under kernel 1.427 and under 1.441.
Looking at the same sequence of steps from ethereal, it seems that
Firefox sends the HTTP GET request, receives a TCP ACK, but then never
receives the actual HTTP reply.

Also, I'm running with net.ipv4.tcp_ecn=0. Setting this to 1 does not
change anything though.

Please let me know if you need any other information.
Comment 1 Gary Peck 2004-06-23 18:14:13 EDT
Created attachment 101364 [details]
tcpdump of successfull connection with kernel-2.6.6-1.427
Comment 2 Gary Peck 2004-06-23 18:15:20 EDT
Created attachment 101365 [details]
tcpdump of unsuccessfull connection with kernel-2.6.7-1.441
Comment 3 Gary Peck 2004-06-23 18:44:25 EDT
Looking at a diff between the two tcpdumps, the only meaningful
differences are:
- In the first (SYN) packet, kernel 1.427 sets a window scale of 0,
whereas kernel 1.441 sets a window scale of 7.
- In the ACK and following HTTP GET from my computer, kernel 1.427
sets a window size of 5840, whereas kernel 1.441 sets a window size of 45.

My TCP/IP knowledge is pretty rusty, so I'm not sure if either of
those are meaningful, but I thought I'd throw it in.
Comment 4 Reuben Farrelly 2004-06-23 18:56:01 EDT
Look at this cset which was committed to the kernel recently:

It's probably easier to do this by hand by simply resetting the 
values in /proc/sys/net/ipv4/*..
See if that makes a difference.  I think it will...temporary 
workaround may be to edit /etc/sysctl.conf and set the value in there.

I too am having problems with the window scale set to 7, Dave Miller 
believes it is a bug with the Cisco IOS Firewall inspection that I 
have in front of my network.  Are you using one of these devices also?
Comment 5 Gary Peck 2004-06-23 19:37:52 EDT
I'll try out tweaking the values in /proc/sys/net/ipv4/ next time I
reboot. I'm not using a Cisco device. The computer experiencing the
problem is behind a Belkin Cable/DSL router. The server I'm connecting
to is in a colocated environment. I'm not sure what routers they're
using over there.
Comment 6 Reuben Farrelly 2004-06-23 19:41:43 EDT
You can temporarily reset these values by hand without rebooting
(eg   echo 0 > /proc/sys/net/ipv4/tcp_default_win_scale  ) will set 
the tcp_default_win_scale to zero which may help your problem.

Comment 7 Gary Peck 2004-06-23 20:02:46 EDT
Right. I meant that I'm currently in an older kernel (2.6.6-1.427)
where all this stuff works. Next time I reboot, I'll do so into one of
the newer kernels (eg. 2.6.7-1.448) and then play around with the proc
Comment 8 Gary Peck 2004-06-25 12:52:55 EDT
Ok, I'm in 2.6.7-1.456 now and setting tcp_default_win_scale=0 fixes
the problem for me too. None of the other parameters in that changeset
(tcp_bic, tcp_moderate_rcvbuf, tcp_vegas_cong_avoid) seem to make a
difference. Values of 1 and 2 also seem to work for tcp_default_win_scale.
Comment 9 Reuben Farrelly 2004-06-25 18:46:46 EDT
I discovered that I also needed to set tcp_moderate_rcvbuf to 0, else 
larger downloads would slow down after a while although they would 
start off good (1 or 2 MB into them, the transfer rate would 
gradually start to reduce).
Comment 10 Steve 2004-08-07 06:53:14 EDT

# echo 0 > /proc/sys/net/ipv4/tcp_default_win_scale
# echo 0 > /proc/sys/net/ipv4/tcp_moderate_rcvbuf

Comment 11 Goh Kim Leng 2004-08-20 13:57:12 EDT
this thread is similar to 
Comment 12 Goh Kim Leng 2004-08-20 14:00:00 EDT
more info at http://lwn.net/Articles/91976/
Comment 13 Dave Jones 2004-11-27 17:34:53 EST
mass update for old bugs:

Is this still a problem in the 2.6.9 based kernel update ?

Note You need to log in before you can comment on or make changes to this bug.