Hide Forgot
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: http://www.trilug.org/pipermail/trilug/Week-of-Mon-20040809/028294.html A discussion of this issue in my LiveJournal is available at: http://www.livejournal.com/users/labrown/89112.html 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: Always 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:
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 32c32 < tcp_bic 0 --- > tcp_bic 1 35c35 < tcp_default_win_scale 0 --- > tcp_default_win_scale 7 49c49 < 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.