Bug 129648 - Cannot reach www.usenix.org with a stock FC2 kernel
Summary: Cannot reach www.usenix.org with a stock FC2 kernel
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: 2
Hardware: i686 Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-08-11 13:22 UTC by Lance A. Brown
Modified: 2015-01-04 22:08 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-17 08:33:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Lance A. Brown 2004-08-11 13:22:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040706 Firefox/0.9.1

Description of problem:
I am unable to reach http://www.usenix.org using any kind of web
browser (lynx, links, GET, mozilla, or firefox).  The browser just
stalls out.  Running 'telnet www.usenix.org 80' and typing into the
telnet session does not provoke a response.

I have confirmed this behaviour personally on 2 different FC2 boxes
and have collected anecdotal evidence from several other people that
they cannot reach it either.

A discussion of this issue on the TriLUG mailing list is available at:

A discussion of this issue in my LiveJournal is available at:

TCP ECN, Path MTU Discovery, and MTU size issues have all be explored
and ruled out.

Someone on TriLUG has built a custom 2.6.7 kernel that works correctly
on his computer where the stock FC2 kernel does not.

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

How reproducible:

Steps to Reproduce:
1. Open a web browser running on a computer with a stock FC2 kernel.
2. Access http://www.usenix.org
3. Watch the browser spin indefinitely until it times out.

Actual Results:  Browser stalls out.

Expected Results:  Displayed web page

Additional info:

Comment 1 Timothy A. Chagnon 2004-08-11 14:04:23 UTC
I've been working with lance on this problem through TriLUG.  Here's a
couple extra notes to add.

I took a look at the traffic in ethereal and this is what happens:
1) DNS lookup shows www.usenix.org as a alias to db.usenix.org
2) SYN;SYN,ACK;ACK handshake between client and db.usenix.org
3) HTTP GET / Request from client, and server ACK of this packet
4) client gets no more packets from server

It's also important to note that this problem only exists in
2.6.7-1.494.2.2 not 2.6.6-1.435.2.3.

We've tried changing various settings in /proc/sys/net/ipv4 without
any luck.  These include ip_no_pmtu_disc, tcp_ecn, tcp_bic,
tcp_default_win_scale, and tcp_moderate_rcvbuf.  I diffed all the
settings in /proc/sys/net/ipv4 between the two kernels and tried
changing the three results.  Here's the diff.

$  diff ipv4-266 ipv4-267
< tcp_bic       0
> tcp_bic       1
< tcp_default_win_scale 0
> tcp_default_win_scale 7
< tcp_moderate_rcvbuf   0
> tcp_moderate_rcvbuf   1

Comment 2 Tom Hughes 2004-08-11 14:57:33 UTC
I see the same problem - setting tcp_default_win_scale to zero seems
to fix it for me. Any non-zero value causes it to fail.

Comment 3 Lance A. Brown 2004-08-11 15:01:08 UTC
I can confirm Tom Hughe's workaround on my system where I originally
saw the problem.  It works.

Comment 4 Timothy A. Chagnon 2004-08-12 22:42:29 UTC
Ah, yes.  I can confirm too.  I must have missed something the first
time I tried to set tcp_default_win_scale to zero.

Comment 5 Tom Hughes 2004-08-14 15:10:10 UTC
It seems www.bugzilla.org has the same problem.

Comment 6 Kyrre Ness Sjøbæk 2004-09-03 14:26:17 UTC
Hmm... The link works for me...

Running FC2 on my laptop with a smoothwall router

Comment 7 Dave Jones 2004-10-26 03:29:46 UTC
should be fixed in an update.

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