Something phenomenal happened. It went "out" but it came back "in". I don't know if it was caused by me or not though.
1. Three FF tabs that I had recently tried to open were still trying to load making me believe that it was happening. 2. Tried to open up some usual sites I go to in links...nope, no go, all stuck on "making connection". ...EXCEPT.... yahoo.com worked for some odd reason, and I mean quickly like there were no dropped packets at all. A wireshark cap confirmed that there were no errors in the connection process from start to finish. This got me thinking, and so I then tried random sites out. Out of about 20 sites I tried, only about 3 worked, linuxquestions.org being one of those three. Since ping / icmp packets never had a problem in lieu of the TCP checksum errors, I tried pinging good & bad sites to see if maybe it was a TTL problem (for example good sites had a high TTL [e.g. less hops] and bad sites had a low TTL) but then I realized that would be inconclusive as I don't know the starting TTL of a received packet. So getting TTLs of 56, 120, and 240 really could be good and bad depending on the starting TTL. The default TTL (/proc/sys/net/ipv4/ip_default_ttl) was 64....I set it to 255 for kicks, but that didn't change anything. I then changed other tcp options (set tcp_sack, tcp_timestamps, tcp_windowscaling off) which seemed like they didn't make a difference as new connection attempts at random hosts hung as well. But somehow sites that I was testing started coming up, which seemed kind of odd 'cause my success rate was like 100%. So then I tried sites that didn't work 5 minutes before and what do you know, they now do. Now I just have to wait for "it" to happen again so I could see if a) repeatedly trying to load yahoo.com or b) changing those /proc values fixes the problem. |
Quote:
Not to mention if it was a bug in a driver, I'm sure there would be more people screaming about it now concerning the circumstances (the computer just sits and has TCP checksum errors). Quote:
Quote:
Either way, after checking around, I found this link: http://wiki.xensource.com/xenwiki/Xe...7cb10110eae9b7 You can always use ethtool to turn of tx checksumming and see if that fixes things. Just some suggestions. |
Yeah I'm pretty sure I'd be able to connect to a game server (if I knew how...don't really play games) if it was through UDP. ICMP (ping) packets are fine too.
It's hard to fully debug this problem because I need to see what the other end sees (and sends). Does the remote server even receive my SYN's or are the packets invalid & they're dropping them? It would be interesting if the tcp checksums mysteriously change. I don't doubt AT&T (my ISP) probably having something to do with it but then again if they were, I should still have the problem after rebooting. That's the big thing....after rebooting the problem is guaranteed to go away which makes me believe it's a software (or hardware initialization) issue. I also tested to see if I get the problem in Windows and I don't, but the problem could be triggered by something that Linux does (or doesn't do) that Windows doesn't do (or does). And what makes it harder is the fact that I haven't figured out what triggers the problem meaning I have to just wait for it to pop up and hope that I'm in the mood to actually do some debugging, which, isn't always. Most times I just say cut the crap and reboot. I tried the suggestions listed on the link but they didn't work because the via-rhine driver in its current state (2.6.25.10) doesn't support offloading (tx or rx). I think the device itself does as I've seen a 2.6.22 patch floating around that enables it, and I might give that a try soon. Code:
# ethtool -k eth0 |
Ok, so I'm most sure this command sequence got me back:
Code:
/proc/sys/net/ipv4# echo 0 > tcp_sack 1. "It" happened 2. After about 2 minutes of "it" happening, I changed the tcp params above 3. "It" was gone on the first connection attempt after changing them. I need to research those params. But what I'm gonna do is throw those into a script. As soon as it happens again, I'm gonna instantly run that script. If I'm back up right after, then the problem resolution has been isolated. |
Figured out the bad parameter:
tcp_timestamps With it enabled = bad. Disabled = good. Keep in mind this is only after "it" happens. Before that (e.g., a fresh reboot), enabled and disabled = good. I found a post that pretty much exactly describes my problem: http://linux.derkeiler.com/Mailing-L.../msg00996.html Quote:
So, I think I am gonna blame it on my ISP...There's probably a traffic-shaping device that's messing with me or a bad box somewhere along some internet routes. I think I can now put this issue to rest and just leave timestamps disabled altogether; thanks to all who offered help & suggestions. |
All times are GMT -5. The time now is 10:05 AM. |