Slashdot Mirror
Google Caught in Comcast Traffic Filtering?
marcan writes "Comcast users are reporting 'connection reset' errors while loading Google. The problem seems to have been coming and going over the past few days, and often disappears only to return a few minutes later. Apparently the problem only affects some of Google's IPs and services. Analysis of the PCAP packet dumps reveals several injected fake RSTs, which are very similar to the ones seen coming from the Great Firewall of China [PDF]. Did Google somehow get caught up in one of Comcast's blacklists, or are the heuristics flagging Google as a file-sharer due to the heavy traffic?"
I'm on Comcast, and haven't had any problems. Doesn't mean they're not doing it elsewhere, but they don't seem to be doing it here.
ZuluPad, the wiki notepad on crack
Starting yesterday my Gmail Notifier Firefox extension stopped working at home where we have Comcast, but at work it works just fine. I thought maybe the plugin had broken due to some API changes or something but I thought it was odd it worked one place and not the other. This really seems like it's related and even though I believe Gmail Notifier is a third party extension, it's still accessing Google's servers.
Comcast is really pissing me off. But what's my other option: Qwest DSL.
Reviewing just the first hour of video games.
It's called DNS caching.
Did you actually flush your DNS caches like, say, the one in your router, the one in your linksys box, the one on your PC? You can do it manually but the quickest way for a lot of equipment is to reboot. Hence the suggestion.
Additionally, it was quite likely google because something on your machine (maybe yourself "trying" the connection) had accessed google while the DNS redirection was in place (that was how they "redirected" you to their page). Once you'd done it once it'd linger until the TTL's had expired all the way back to your computer. Ping, nslookup, etc. would ALL show the Comcast IP until that happened, which could be minutes, hours, days, months, depending on your setup.
In your case, it looks like it was less than 24-hours, because it worked the next day without having to reboot. If you had rebooted immediately, it would have all worked when it came back up. That's WHY he was telling you that.
Before you start throwing accusations around, delve into such things just a little bit deeper.
You're looking at the date the posters joined the forum, not the date of the post.
Your OWN COMPUTER was redirecting you to Comcast (maybe you should be indignant towards Microsoft? >_>). It's called DNS caching.
In Windows a simple ipconfig /flushdns can take care of that, although some applications, such as Firefox, keep their own DNS caches which must also be cleared (In Firefox there's a DNS cache timeout in about:config somewhere, you just set it to 0 and then back and that should flush the cache).
Also the tech was almost right... restarting your computer WOULD have fixed it (since DNS caches are only kept in memory and would have been wiped when you rebooted) although it wouldn't have been the OPTIMAL solution.
Let me take you through the steps your computer took.
Someone knowledgeable about this issue should update the wikipedia page about sandvine.
The way it's written now, everyone should use Sandvine - it sounds like wonderful software.
Lol.. I wasn't talking only about myself. I surf at -1 and see a lot of the comments modded down. And yes, I know when something is off topic like this is.
You wouldn't happen to be one of the people I talked about attempting to dispel knowledge of this are you? There we go, the tinfoil hat is back in place and everythign feels right again.
Either look around or keep your eyes shut. It doesn't matter much to me. But I call them as I see them. I haven't been wrong often.
This had me up far too late yesterday trying to figure out WTF is going on.
.pcap format if you'd like to take a look.
Here's the condensed version:
* Pings work fine, other websites work fine - only HTTP to google.com with a "google.com" host header is affected
* HTTP 1.0 without host header isn't affected
* Going to one of google's web servers by IP works fine (no "google.com" host header)
* I am typically seeding torrents and was at the time of each service interruption
* TCP RSTs follow a specific pattern. 2 RSTs in rapid succession in response to the initial GET statement (1 with a valid SEQ, one with a SEQ in the 12xxx range), followed by a second batch of the same. As the article here states (and as I posted in the linked thread), this matches perfectly with results from the China firewall
* The problem went away at almost exactly 12:00am EDT this morning (give or take a minute)
* This is from a Comcast subscriber in Grand Rapids, MI.
For more detail, visit the thread linked. I have links to the raw packet capture data in
I'm on a Comcast business account. I recently had a problem where a working, light loaded Postfix installation suddenly had 10-20% of my outbound email traffic just hang. Verbose logging showed that the problem always occured at the DNS query stage. Mail sent through a backup server suffered the same fate.
Using tcpdump showed that all the bad dns queries stopped after 4 frames, while the successful ones went 68 or 70 frames.
Switching from Comcast's regional DNS servers to their national DNS servers fixed the problem immediately.
Makes me wonder what they're doing on the regional ones.
Never shake hands with a man you meet in a fertility clinic.
Just hoping for an informative here:
I believe that 4.2.2.1 - 4.2.2.5 (or maybe 6) are all DNS servers for Level3, in case you want multiples available.
My blog. Good stuff (when I remember to update it). Read it.