Cox HSI Dropping P2P/Gnutella/WinMX Upload Traffic

The following is a compilation of posts I made to the Broadband Reports Cox HSI Forum. I am archiving it here for posterity and in the hopes that someone else may come across this and can use my findings and take them further, and that maybe Cox will come clean after they realize people aren’t happy.

After much research it has become clear that Cox is selectively monitoring and dropping certain P2P (Gnutella) traffic. I am in the San Diego area, so I do not know if this applies elsewhere.

Some details:

1) Cox is NOT blocking P2P traffic. “DROPPING” is the proper term.
2) This may be Gnutella specific. Soulseek and BitTorrent both still work fine. I am not sure about other file sharing networks, although there have been reports that WinMX is having the same problems.
2) Cox is selectively targeting UPLOADS only. All other aspects of Gnutella network activity (host connections, downloads) work fine.
3) On uploads, connections are reset right after the HTTP 401 Authorization is given by the uploader. Here’s a little graph to demonstrate (client on left, server on right):
CLIENT ==> sends out search
returns matches <== SERVER
CLIENT ==> sends HTTP GET request
sends HTTP 401 Auth <== SERVER

Sample conversation:
Upload to X.X.X.X:6346 ("BearShare Lite") Processing request
GET /uri-res/N2R?urn:sha1:123412341234123412341234 HTTP/1.1\r\n
Host: \r\n
User-Agent: BearShare Lite\r\n
Range: bytes=0-324965\r\n
Content-Disposition: inline; filename=somefile.mp3\r\n
X-Queue: 0.1\r\n
X-Gnutella-Content-URN: urn:sha1:123412341234123412341234\r\n
X-Connection-Type: Broadband\r\n
FP-1a: \r\n
X-Features: queue/0.1\r\n
X-Node: X.X.X.X:6346\r\n
HTTP/1.1 401 Authorizing\r\n
Server: BearShare 4.7.0b38\r\n
Content-Length: 0\r\n
FP-1b: \r\n

(At this point the connection is reset)

4) In a firewalled situation, outbound GIVs from a firewalled user are reset right after the GIV is received.
5) Cox is sniffing/dropping based on the DATA field of the TCP packet, NOT the packet header (source/dest ports), because uploads are dropped even while running over non-standard (6346) ports.
6) I’m not 100% positive, but Cox may allow uploads to other Cox subscribers in the same area. A few rare uploads slipped through to other Cox subscribers during my early testing. This may have just been a glitch/oversight in their traffic sniffer that has recently been fixed, because I have not seen a successful upload in weeks since. But for sure, all uploads heading outside the Cox area are dropped.

In the below TCPDump you will see a Bell South customer attempt to download a file from me. He makes two attempts. (LOCAL.PORT is me, note PORT is NOT 6346, but another random port, with NAT port forwarding, so I am effectively not firewalled)

19:56:00.598539 IP > LOCAL.PORT: S 910058714:910058714(0) win 65535
19:56:00.598624 IP LOCAL.PORT > S 591457694:591457694(0) ack 910058715 win 65535
19:56:00.714254 IP > LOCAL.PORT: . ack 1 win 65535
19:56:00.725367 IP > LOCAL.PORT: P 1:251(250) ack 1 win 65535
19:56:00.731713 IP > LOCAL.PORT: R 910058965:910058965(0) win 10240
19:56:00.732075 IP > LOCAL.PORT: R 910071468:910071468(0) win 10240
19:56:00.736472 IP > LOCAL.PORT: R 910058971:910058971(0) win 10240
19:56:00.736840 IP > LOCAL.PORT: R 910071474:910071474(0) win 10240

19:57:01.850407 IP > LOCAL.PORT: S 2222769745:2222769745(0) win 65535
19:57:01.850485 IP LOCAL.PORT > S 2025320299:2025320299(0) ack 2222769746 win 65535
19:57:01.982241 IP > LOCAL.PORT: . ack 1 win 65535
19:57:01.993511 IP > LOCAL.PORT: P 1:251(250) ack 1 win 65535
19:57:01.999252 IP > LOCAL.PORT: R 2222769996:2222769996(0) win 10240
19:57:01.999618 IP > LOCAL.PORT: R 2222782499:2222782499(0) win 10240
19:57:02.003452 IP > LOCAL.PORT: R 2222770002:2222770002(0) win 10240
19:57:02.003816 IP > LOCAL.PORT: R 2222782505:2222782505(0) win 10240

EQUIVALENT BS LOGS (one for each attempt):
Upload from ("LimeWire/4.0.8") Processing request
User-Agent: LimeWire/4.0.8\r\n
X-Queue: 0.1\r\n
X-Gnutella-Content-URN: urn:sha1:RJXSPMRB6EZO36USTVEQREOP6XFAM5KX\r\n
Range: bytes=0-99999\r\n
X-Features: queue/0.1\r\n
HTTP/1.1 206 Partial Content\r\n
Cache-Control: no-cache\r\n
Server: BearShare 4.7.0b54\r\n
Content-Type: audio/mpeg\r\n
Content-Length: 100000\r\n
Content-Range: bytes 0-99999/6213632\r\n
X-Gnutella-Content-URN: urn:sha1:RJXSPMRB6EZO36USTVEQREOP6XFAM5KX\r\n
X-Create-Time: 1082000768000\r\n
X-Features: chat/0.1, queue/0.1\r\n
fileBytes: 6213632
szFileName: "somefile.mp3"
szBaseName: "D:\some\path"

Here’s an upload attempt using -nettt, windump output on top, Bearshare console output on the bottom.
000000 00:06:25:ea:40:b9 > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 62: IP > 192.168.X.X.MYPORT: S 790131918:790131918(0) win 65535
000090 XX:XX:XX:XX:XX:XX > 00:06:25:ea:40:b9, ethertype IPv4 (0x0800), length 62: IP 192.168.X.X.MYPORT > S 107096962:107096962(0) ack 790131919 win 65535
061333 00:06:25:ea:40:b9 > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 60: IP > 192.168.X.X.MYPORT: . ack 1 win 65535
015100 00:06:25:ea:40:b9 > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 635: IP > 192.168.X.X.MYPORT: P 1:582(581) ack1 win 65535
004598 00:06:25:ea:40:b9 > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 60: IP > 192.168.X.X.MYPORT: R 790132500:790132500(0) win 10240
000360 00:06:25:ea:40:b9 > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 60: IP > 192.168.X.X.MYPORT: R 790145003:790145003(0) win 10240
005326 00:06:25:ea:40:b9 > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 60: IP > 192.168.X.X.MYPORT: R 790132506:790132506(0) win 10240
000381 00:06:25:ea:40:b9 > XX:XX:XX:XX:XX:XX, ethertype IPv4 (0x0800), length 60: IP > 192.168.X.X.MYPORT: R 790145009:790145009(0) win 10240Upload from ("BearShare") Processing request
User-Agent: BearShare\r\n
Range: bytes=3932160-4194303\r\n
X-Gnutella-Content-URN: urn:sha1:PZWSAFKCQSRZ32CZSKXBUH4VCMMH7M2K\r\n
X-Connection-Type: Broadband\r\n
FP-1a: \r\n
Content-Disposition: inline; filename="somefile.mp3"\r\n
X-Features: browse/1.0, queue/0.1\r\n
X-Queue: 0.1\r\n
HTTP/1.1 401 Authorizing\r\n
Server: BearShare 4.7.0b57\r\n
Content-Length: 0\r\n
FP-1b: \r\n
X-Features: chat/0.1, queue/0.1\r\n

Cox is sniffing the data field of the TCP packet. So any sort of P2P communication gets dropped by matching the strings that P2P apps use in their handshakes (presumably). So no matter what port your P2P is on, packets will still get dropped simply because of the fact that they are using well-known and publically available P2P handshakes. The other option is to encrypt all P2P handshakes and communication. At that point Cox couldn’t succeed using this method because all their scanners would see is a bunch of jibberish passing through the lines. I’ve talked to some of the P2P developers about that, and while encryption is on their “wish list” it requires a fundamental overhaul of the P2P apps’ codebases, and is a big investment in time and money. In otherwords, encrypted connections won’t be coming to P2P any time soon.

This is a pretty sneaky move by Cox, because it keeps their users happy by allowing downloads, and keeps the RIAA happy by disallowing uploads. However, Cox is interfering with their customers’ outbound connections without their knowledge, and crippling legitimate uses for P2P networks (the debate over whether P2P is “server-based” and against Cox’s TOS is for another day/thread). It’s even more ironic that Cox recently ran a TV commercial for HSI, and one of the reasons they suggest getting Cox HSI is to “fill up that new iPod you just got for Christmas.” In other words, Cox is promoting drug use, but preventing drug dealing – having their cake and eating it too.

I was hoping this post would stay a technical one and not a philosophical one, but if Cox is allowing downloads, they need to allow uploads too. There are no gray areas in piracy. Either you allow it or you don’t.

If your argument is that uploads harm the quality of the network, Cox should at least allow a percentage of upload traffic through (proportional to the 4Mbit down/512Kbit up ratio), and not block ALL upload traffic.

Lets be honest here. Cox is dropping P2P upload packets because of pressure from the RIAA, it has nothing to do with network health.

The sneaky part of it is that they’re doing it unannounced, “behind our backs” if you will. Cox clearly states on their tech support pages that they block port 25 and other ports. And THAT IS FINE, because you know what you’re getting when you sign up. But ask a Cox technician if they are blocking P2P and they either won’t answer or deny it, and I don’t see it listed anywhere on their websites. Why? Because NO ONE WOULD SUBSCRIBE TO COX IF PEOPLE KNEW THEY WERE BLOCKING P2P. Like porn, music/movie/software piracy is what drives Cox’s business model, and the Internet as a whole. Imagine what would happen to their subscriptions if Cox came out and announced that P2P was blocked. BYE BYE COX.

When someone buys a service or product, they need to know what they get in return for their money. Cox needs to come clean and either stop blocking P2P, or clearly state that they do so in their TOS and on their websites. This, no one can deny, is a fact.

UPDATE: Looks like there’s an online petition to tell Cox to knock it off. Sign Up Here.

5 responses to “Cox HSI Dropping P2P/Gnutella/WinMX Upload Traffic”

  1. cc says:

    is there a followup to this story? are you still have these issues or have you discovered anything else?

  2. texan says:

    I pay a premium $price$ for my cable internet. I have rented a toshiba cable modem for over 2 years now. They have made VERY much money off of me. I actually think their service is “overpriced”!! It is truly a shame that even though they are getting their money that they will block uploads. Especially without telling their customers!!!!!!!!!! This is just ridiculous. But you know, I have heard that SBC is soon to announce that they will offer their customers in 13 states that receive their telephone service, that they will offer DSL for the “amazing” price of $15.95 monthly. I say goodbye Cox, hello SBC. And I will let Cox know about it too!!!!!!!

  3. Jdubya says:

    I just got off the screen with cox Chat support.

    He claims they are not filtering Gnuettela packets, yet my results validate your claims.

    Where do we go from here? They have no public policy regarding the issue and are lying to us.

  4. jordan says:

    I have been having problems with WinMX, I can’t upload. I can download fine, but all my uploads time out. I have COX and have just realised that all the port switching in the world won’t help me. I am mad and COX suck Cocks.

  5. mark says:

    We are with Cox in San Pedro, CA. and having the exact same problem – No Uploads. Funny thing though, BearShare and LimeWire uploads worked just fine for about 1 month on 2 different computers while connected to a router behind the cable modem.

    Then one day nothing but “resets” for BearShare and “transfers interrupted” for LimeWire.

    I tested, troubleshooted and asked Cox tech support 2 times for assistance and if they are blocking P2P uploads. Each time a rep from Cox claims they are not blocking any ports or uploads. They tell me to try it without the router as that must be the problem. Well, I have done that also…. Uploads still are reset and transfers interrupted right away.

    I also believe Cox is guilty of deceptive practice by dropping P2P uploads without disclosure.

    This would make a good controversial TV news story!