As fate (or rather, failure to research local broadband monopolies and factor them into my home-buying decisions) would have it, I am a Comcast cable internet customer, in a Comcast town. As you might now, Comcast has for some time been quietly blocking…er, the polite term is “throttling”, certain types of bandwidth-intensive traffic. While that traditionally has meant BitTorrent (to cite the most well-publicized example), several researchers have presented evidence showing Comcast interfering with other types of traffic, such as Gnutella and even Lotus Notes. Comcast of course openly denies any “blocking” of “applications”* using lawyeresque weasel-words, in effect tacitly admitting to interference that falls just short of outright blocking. (The admission is typically couched in terms such as “traffic management to ensure the best service for everybody”, which is marketing speak for “we ridiculously oversold our capacity, and are blaming Bad Customers** for our mistake. Phooey on them, wanting to actually use the bandwidth they paid for and such.”.) From a technical standpoint, Comcast’s blocking throttling is done using a Sandvine box to sniff the user’s packet stream for possible P2P connections, then inject fake packets into the stream (known as a man-in-the-middle attack). Comcast sends fake RST (reset) packets to both the sender and receiver, spoofed to appear as though the other side sent them. This results in both sides dropping the connection, typically appearing as a “Connection reset by peer” error if the program actually displays errors. BitTorrent clients typically don’t, but other affected programs might.
I have personally found evidence that suggests Comcast’s ham-handed blocking attempts have been interfering with even other types of legitimate traffic, including FTP, VNC and GMail. Yes, Gmail.
Gmail:
Intermittently, certain activities in Gmail (mainly, attempting to send an email with file attachments, although the Chat feature is intermittently affected as well) at home would fail in various nondescript ways – for example, just sit there and do nothing, or pop up a bizarre, title-less lowercase “please try again” Javascript popup that even Google’s tech support couldn’t identify. Of course, trying it from my work connection (same browser version, approximately same time, by the power vested in me by VNC) would always work fine. This would persist for several days at a time, then go away for a while, then come back…
Solution: During one particularly extended period of brokenness, I tried changing the standard “http://” URL to “https://” to force an encrypted connection, and reloaded the page. Lo and behold, everything now worked flawlessly! The only difference “https://” makes is it uses a different portnumber and the traffic stream is encrypted. On Gmail’s side, the same requests are answered by the same scripts, then sent back to me and read by the same browser. The only difference is that Comcast can’t snoop the streams, misdetect one as a bandwidth-hungry file transfer and inject crap into the conversation.
VNC:
Occasionally, I have a need to pull data from my home machine to my work machine, or run a program on my home machine that I can’t or don’t want to re-install at work, so I run a VNC server at home. One day, I could not connect to it from work, although nothing had changed (including IP address) and the server was definitely running (I could connect to it from other machines at home). Likewise, the VNC client at work could connect to other machines, just not on Comcast. Our IT guy at work also reported difficulty with his Comcast connection. Upgrading to the latest version of TightVNC, which uses a newer protocol, on both sides solved it. (So it seems that either my client and server both experienced bit rot, or a certain ISP decided not to like the protocol.)
FTP:
Trying to upload large files to my Web site has been failing with repeated “Connection reset by peer” errors after only a few megs have been transferred. I can let my FTP client run overnight, trying to post 30-meg videos with arbitrarily many retries, and by the morning not a single file has successfully transferred. Hmm, I said. Connection RESETs, that appear to be coming from the peer, why does this sound familiar…? Now to test a theory. As I let the FTP continue to run and fail, I research and find that my Web host supports Secure FTP, which boasts end-to-end encryption. So with only a couple-minute delay to download and install a SFTP client, I replace this simple, time-honored protocol with a CPU-hungry encrypted version, and guess what? The screenshots may speak for themselves.
Unencrypted file transfer over Comcast: no successes. Encrypted transfers over Comcast: no failures!
So it seems, if you’re stuck with Comcast, any type of transfer that doesn’t fit their preferred usage profile (that is, a granny paying $45/mo to send a couple short emails every week) is a potential target for packet discrimination during times of peak demand***. It also seems that the solution so far involves encrypting or obfuscating as much of your traffic as possible. The stream then appears as random noise, and no man-in-the-middle crap can be injected without invalidating the signature. Comcast in my area doesn’t seem to be blanket-blocking encrypted traffic (yet!), so this can be an interim solution while counting down the days until FIOS (or any competition what-so-bloody-ever) is available in your Comcast Town.
(Finally, for actual p2p transfers, this link provides instructions for enabling encryption in BT, as well as some other workarounds.)
* they don’t block applications, they block packets from those applications. The applications themselves are installed on your own PC, which they can’t do anything about without deploying a rootkit.
**there is actually a commercial to this effect running as part of the cable/satellite TV wars, but I couldn’t find a link to it. A bunch of fatcat executives are sitting around a downward-spiralling profits graph, one exclaiming, “I’ve figured out the problem! It’s the CUSTOMERS. They keep calling, and complaining, and wanting better service.” The solution was to fire all the customers and find replacement customers who were more willing to accept crappy service.
***it’s possible that these issues manifest only for users who occasionally run one of the targeted applications, such as BitTorrent (which my housemate often does). Since it is unlikely that even CrapCast would intentionally target e.g. GMail, it may be that their braindead filter just nukes TCP streams from your modem indiscriminately if recetn BitTorrent activity has been detected. Further study will be performed when I can set up a clean test at a friend’s house with Wireshark running on both sides, as the Lotus Notes guy did.
Leave a Reply