Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Description of problem: Network connectivity problems when trying to connect to websites by either using: Firefox, wget, telnet or (ssh tunnel + hosts file change) When trying to connect to http://www.enterprisegroupwaresystem.org/ or http://dev.mysql.com the network just doesn't respond after the second ACK. No. Time Source Destination Protocol Info 7 2.970186 192.168.0.2 195.182.4.55 TCP 56271 > http [SYN] Seq=0 Len=0 MSS=1452 T SV=27259478 TSER=0 WS=7 Frame 7 (74 bytes on wire, 74 bytes captured) Ethernet II, Src: AsustekC_fc:97:18 (00:13:d4:fc:97:18), Dst: Netgear_82:ae:6e (00:09:5b:82:ae:6e) Internet Protocol, Src: 192.168.0.2 (192.168.0.2), Dst: 195.182.4.55 (195.182.4.55) Transmission Control Protocol, Src Port: 56271 (56271), Dst Port: http (80), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 8 3.075324 195.182.4.55 192.168.0.2 TCP http > 56271 [SYN, ACK] Seq=0 Ack=1 Win=1 6384 Len=0 MSS=1452 WS=0 TSV=818469626 TSER=27259478 Frame 8 (78 bytes on wire, 78 bytes captured) Ethernet II, Src: Netgear_82:ae:6e (00:09:5b:82:ae:6e), Dst: AsustekC_fc:97:18 (00:13:d4:fc:97:18) Internet Protocol, Src: 195.182.4.55 (195.182.4.55), Dst: 192.168.0.2 (192.168.0.2) Transmission Control Protocol, Src Port: http (80), Dst Port: 56271 (56271), Seq: 0, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 9 3.075388 192.168.0.2 195.182.4.55 TCP 56271 > http [ACK] Seq=1 Ack=1 Win=5888 L en=0 TSV=27259583 TSER=818469626 Frame 9 (66 bytes on wire, 66 bytes captured) Ethernet II, Src: AsustekC_fc:97:18 (00:13:d4:fc:97:18), Dst: Netgear_82:ae:6e (00:09:5b:82:ae:6e) Internet Protocol, Src: 192.168.0.2 (192.168.0.2), Dst: 195.182.4.55 (195.182.4.55) Transmission Control Protocol, Src Port: 56271 (56271), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 10 3.075526 192.168.0.2 195.182.4.55 HTTP GET / HTTP/1.1 Frame 10 (468 bytes on wire, 468 bytes captured) Ethernet II, Src: AsustekC_fc:97:18 (00:13:d4:fc:97:18), Dst: Netgear_82:ae:6e (00:09:5b:82:ae:6e) Internet Protocol, Src: 192.168.0.2 (192.168.0.2), Dst: 195.182.4.55 (195.182.4.55) Transmission Control Protocol, Src Port: 56271 (56271), Dst Port: http (80), Seq: 1, Ack: 1, Len: 402 Hypertext Transfer Protocol No. Time Source Destination Protocol Info 13 3.383316 195.182.4.55 192.168.0.2 TCP http > 56271 [ACK] Seq=1 Ack=403 Win=1728 0 Len=0 TSV=818469626 TSER=27259583 Frame 13 (66 bytes on wire, 66 bytes captured) Ethernet II, Src: Netgear_82:ae:6e (00:09:5b:82:ae:6e), Dst: AsustekC_fc:97:18 (00:13:d4:fc:97:18) Internet Protocol, Src: 195.182.4.55 (195.182.4.55), Dst: 192.168.0.2 (192.168.0.2) Transmission Control Protocol, Src Port: http (80), Dst Port: 56271 (56271), Seq: 1, Ack: 403, Len: 0 Version-Release number of selected component (if applicable): 2.6.18-1.2849.fc6 How reproducible: Always Steps to Reproduce: 1. point forefox to the links 2. or use wget on the links 3. or use telnet on port 80 and manually do HTTP commands on the hosts 4. ssh tunnel + hosts change is a bit more involved Actual Results: Network traffic is halted for that link. Expected Results: Network traffic should continue until either SIGPIPE happens or until FIN. Additional info: Another computer that is one router further away from (beneath) the machine I have a problem with is able to contact and show above sites with no problems (Mac OSX 10.3.9.) Another machine running FC5 has the same problem (not going through any router but directly to ADSL.) FC3 seems ok. FC4 derivative works as well.
IPv6 is off Ethernet device is forcedeth FW is off Other network activity seems 100% ok Dual core AMD CPU ACPI is on 3 GB main memory
I seem to recall a tcp window scaling bugzilla ticket somewhere that sounds very similar... Ah, there it is. I'm inclined to think this is a duplicate of bug 207373. Try out the suggestions from comment #13 of bug 207373 and see if that doesn't help your situation.
That is exactly what it was (tcp_window_scaling). Sorry for the dup and my inability to find it. I would say though that it can't be my router because on a different setup (FC5) the router in question is not even in the mix... so this problem is on ISP level or maybe even on the server side. Anyhow added: net.ipv4.tcp_window_scaling = 0 to /etc/sysctl.conf Maybe this should be the default in Fedora? Thanks!
No worries, searches here somewhat stupidly default to not looking at closed bugs, so lots of dupes get missed... :( Anyhow, no, we don't want to make it the default, that just papers over the fact there are broken routers out there. Better to get 'em fixed. :) Maybe its something we should add to the release notes and/or the FC6 common issues wiki page... *** This bug has been marked as a duplicate of 207373 ***