From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
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):
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
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
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.
I can confirm Tom Hughe's workaround on my system where I originally
saw the problem. It works.
Ah, yes. I can confirm too. I must have missed something the first
time I tried to set tcp_default_win_scale to zero.
It seems www.bugzilla.org has the same problem.
Hmm... The link works for me...
Running FC2 on my laptop with a smoothwall router
should be fixed in an update.