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
!!!! CONNECTION MAGICALLY RESET !!!
Sample conversation:
Upload to X.X.X.X:6346 ("BearShare Lite 4.5.0.63") Processing request
--REQUEST--
GET /uri-res/N2R?urn:sha1:123412341234123412341234 HTTP/1.1\r\n
Host: \r\n
User-Agent: BearShare Lite 4.5.0.63\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
FP-Auth-Challenge: JUKZSOUFLZ2TOG2KAILXH34JA7WJWK3J\r\n
X-Features: queue/0.1\r\n
X-Node: X.X.X.X:6346\r\n
\r\n--RESPONSE--
HTTP/1.1 401 Authorizing\r\n
Server: BearShare 4.7.0b38\r\n
Content-Length: 0\r\n
FP-1b: \r\n
\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)

1ST ATTEMPT
19:56:00.598539 IP adsl-1-139-33.clt.bellsouth.net.50736 > LOCAL.PORT: S 910058714:910058714(0) win 65535
19:56:00.598624 IP LOCAL.PORT > adsl-1-139-33.clt.bellsouth.net.50736: S 591457694:591457694(0) ack 910058715 win 65535
19:56:00.714254 IP adsl-1-139-33.clt.bellsouth.net.50736 > LOCAL.PORT: . ack 1 win 65535
19:56:00.725367 IP adsl-1-139-33.clt.bellsouth.net.50736 > LOCAL.PORT: P 1:251(250) ack 1 win 65535
19:56:00.731713 IP adsl-1-139-33.clt.bellsouth.net.50736 > LOCAL.PORT: R 910058965:910058965(0) win 10240
19:56:00.732075 IP adsl-1-139-33.clt.bellsouth.net.50736 > LOCAL.PORT: R 910071468:910071468(0) win 10240
19:56:00.736472 IP adsl-1-139-33.clt.bellsouth.net.50736 > LOCAL.PORT: R 910058971:910058971(0) win 10240
19:56:00.736840 IP adsl-1-139-33.clt.bellsouth.net.50736 > LOCAL.PORT: R 910071474:910071474(0) win 10240
2ND ATTEMPT
19:57:01.850407 IP adsl-1-139-33.clt.bellsouth.net.50747 > LOCAL.PORT: S 2222769745:2222769745(0) win 65535
19:57:01.850485 IP LOCAL.PORT > adsl-1-139-33.clt.bellsouth.net.50747: S 2025320299:2025320299(0) ack 2222769746 win 65535
19:57:01.982241 IP adsl-1-139-33.clt.bellsouth.net.50747 > LOCAL.PORT: . ack 1 win 65535
19:57:01.993511 IP adsl-1-139-33.clt.bellsouth.net.50747 > LOCAL.PORT: P 1:251(250) ack 1 win 65535
19:57:01.999252 IP adsl-1-139-33.clt.bellsouth.net.50747 > LOCAL.PORT: R 2222769996:2222769996(0) win 10240
19:57:01.999618 IP adsl-1-139-33.clt.bellsouth.net.50747 > LOCAL.PORT: R 2222782499:2222782499(0) win 10240
19:57:02.003452 IP adsl-1-139-33.clt.bellsouth.net.50747 > LOCAL.PORT: R 2222770002:2222770002(0) win 10240
19:57:02.003816 IP adsl-1-139-33.clt.bellsouth.net.50747 > LOCAL.PORT: R 2222782505:2222782505(0) win 10240
EQUIVALENT BS LOGS (one for each attempt):
Upload from 65.1.139.33 ("LimeWire/4.0.8") Processing request
--REQUEST--
GET /uri-res/N2R?urn:sha1:RJXSPMRB6EZO36USTVEQREOP6XFAM5KX HTTP/1.1\r\n
HOST: XXX.XXX.XXX.XXX:PORT\r\n
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
\r\n--RESPONSE--
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
\r\n--RESPONSE FILE--
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 24.243.4.6.1773 > 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 > 24.243.4.6.1773: 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 24.243.4.6.1773 > 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 24.243.4.6.1773 > 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 24.243.4.6.1773 > 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 24.243.4.6.1773 > 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 24.243.4.6.1773 > 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 24.243.4.6.1773 > 192.168.X.X.MYPORT: R 790145009:790145009(0) win 10240Upload from 24.243.4.6 ("BearShare 4.6.2.1") Processing request
--REQUEST--
GET /uri-res/N2R?urn:sha1:PZWSAFKCQSRZ32CZSKXBUH4VCMMH7M2K HTTP/1.1\r\n
Host: IP.IP.IP.IP:MYPORT\r\n
User-Agent: BearShare 4.6.2.1\r\n
Range: bytes=3932160-4194303\r\n
X-NAlt: IP.IP.IP.IP:MYPORT\r\n
X-Gnutella-Content-URN: urn:sha1:PZWSAFKCQSRZ32CZSKXBUH4VCMMH7M2K\r\n
X-Connection-Type: Broadband\r\n
FP-1a: \r\n
FP-Auth-Challenge: NAAVOYFU5T7NZJ666YT5VCJDRICINWJM\r\n
Content-Disposition: inline; filename="somefile.mp3"\r\n
X-Features: browse/1.0, queue/0.1\r\n
X-Node: 24.243.4.6:6346\r\n
X-Queue: 0.1\r\n
\r\n--RESPONSE--
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
\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.