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?"

7 of 385 comments (clear)

  1. Gmail Notifier by hansamurai · · Score: 4, Informative

    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.

  2. Re:First hand experience here by ledow · · Score: 5, Informative

    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.

  3. Re:Can we please pay attention to the dates... by marx · · Score: 3, Informative

    You're looking at the date the posters joined the forum, not the date of the post.

  4. Wikipedia page by sunderland56 · · Score: 4, Informative

    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.

  5. Re:Not me... by Shakrai · · Score: 5, Informative

    But in this case it just sounds like they can't figure out how to do it right.

    It's not that they can't figure it out, it's that they aren't even bothering to try and shape traffic. They'd rather interfere with it.

    Back in my ISP days we ran our entire operation (400 dial-in lines and about 60 WISP clients) off two un-bonded T-1s (they went to different POPs for redundancy). We couldn't afford to add more bandwidth at the edge, so I hacked together a traffic shaping setup using Linux. It prioritized ssh, telnet, TCP ACKs, icmp packets, and the VPNs of our business clients. VoIP wasn't a big concern in those days but had it been I would have prioritized it as well. When online gaming started becoming big we started giving that traffic priority over bulk transfers as well.

    The bulk downloaders/p2p'ers didn't notice or complain. They still got the lions share of the bandwidth -- and are you really going to notice if your transfer gets 139KB/s instead of 140KB/s due to that ssh packet moving ahead of you in the queue? During peak hours my T-1s were running at 90-95% of capacity but my users were all still humming along quite nicely, none the wiser. There was more to this then just traffic shaping (we also had a pretty slick squid setup), but the point is we got along just fine with our limited resources.

    If we could fucking do it, then sure as hell Comcast could. They have apparently decided that it's better to block/drop the traffic then shape it. If they had real competition they'd probably pay for this over the long run.

    --
    I want peace on earth and goodwill toward man.
    We are the United States Government! We don't do that sort of thing.
  6. Re:Not me... by ChromaticDragon · · Score: 5, Informative

    I'm rather certain the root of your woes is Comcast. I am not certain it's intentional.

    Furthermore, the problem is very likely far more simple and less sophisticated than this issue of packet spoofing.

    Set up a continuous ping to something "nearby" (your gateway, your DNS ser ver, your neighbor, whatever) in your Comcast network and tee it to a file. Leave it up for days and you'll likely see periods of time where you have no service for patches of time... often long enough to kill sessions.

    I very often have problems with any sort of sessions (SSH, VPN, etc.) staying up for long periods of time because the underlying line level reliability is so poor. I can watch my cable modem logs and see many resets, timeouts, etc.

    I laugh whenever asked about phone service via Comcast. Sadly, however, this pathetic reliability also precludes Vonage and the like. And I find this a bit sad since while I do not consider Comcast capable of running a world class network, I loathe the phone company. Those guys are more competent but much more directly evil.

  7. Re:Not me... by zappepcs · · Score: 3, Informative

    choke on it... it IS comcast. Your intermittent problems keeping a session open are inarguably unacceptable in view of the wider experience of broadband users in North America. My provider is rock solid in my area. I regularly keep open as many as 6 sessions that do not see lost packets, never mind service unavailable. for example: active SL connection(s), Vonage call, Internet Radio, NNTP session, and active web browsing. None of these suffer a problem. In fact, the only problems I've had were / are on the wireless links. My microwave and wireless router apparently disagree on the topic of which is more powerful.

    If we look at what is promised, what is purchased, what is possible, and compare that to what is experienced, it is clear that some ISPs suck, and there is a reason that they suck. Suckiness is not 'normal' or 'average' or acceptable. With the FCC ruling to allow multiple ISP connectivity to many homes, the quality of service should improve to prevent customer churn. My advice is to switch if complaints are not resolved if you can. If not, register a complaint with the authority who gave your ISP broadband monopoly in your area. Document the complaint process and responses. The BBB, I believe, can be consulted in cases where they clearly are not giving you what you paid for.