Bug 126626

Summary: network connection problem with 2.6.7-1.441 and up
Product: [Fedora] Fedora Reporter: Gary Peck <gbpeck>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED RAWHIDE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: rawhideCC: gohkl, pfrields, p.van.egdom, reuben-redhatbugzilla, twaugh, zuirdj
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-10-06 00:01:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
tcpdump of successfull connection with kernel-2.6.6-1.427
none
tcpdump of unsuccessfull connection with kernel-2.6.7-1.441 none

Description Gary Peck 2004-06-23 22:03:01 UTC 
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):
kernel-2.6.7-1.448

How reproducible:
Always

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

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 22:14:13 UTC 
Created attachment 101364 [details]
tcpdump of successfull connection with kernel-2.6.6-1.427
Comment 2 Gary Peck 2004-06-23 22:15:20 UTC 
Created attachment 101365 [details]
tcpdump of unsuccessfull connection with kernel-2.6.7-1.441
Comment 3 Gary Peck 2004-06-23 22:44:25 UTC 
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 22:56:01 UTC 
Look at this cset which was committed to the kernel recently:
http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/cset-
davem.net|ChangeSet|20040616043521|55919.txt

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 23:37:52 UTC 
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 23:41:43 UTC 
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-24 00:02:46 UTC 
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
values.
Comment 8 Gary Peck 2004-06-25 16:52:55 UTC 
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 22:46:46 UTC 
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 10:53:14 UTC 
kernel-smp-2.6.7-1.494.2.2

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

merci!
Comment 11 Goh Kim Leng 2004-08-20 17:57:12 UTC 
this thread is similar to 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129204
Comment 12 Goh Kim Leng 2004-08-20 18:00:00 UTC 
more info at http://lwn.net/Articles/91976/
Comment 13 Dave Jones 2004-11-27 22:34:53 UTC 
mass update for old bugs:

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