> Well...Cox are as the name suggests. They're not p2p friendly. I'd take a wild guess & say that your problem is there.
I think you're right.
> If you use the forum search to look for Cox, you'll find heaps of threads where people have had trouble (mostly with connection & downloads though). Search for no uploads Cox & you'll see you're not the only one who's had this happen.
I did a search on the internet, and sure enough; I found lots of discussion about Cox blocking uploads from happening.
Here's what Cox does (feel free to repost this):
Cox is dropping (not blocking) P2P traffic
After much research it has become clear that Cox is selectively monitoring and dropping certain P2P (Gnutella) traffic.
Some details:
1) Cox is NOT blocking P2P traffic. The proper term is DROPPING P2P traffic.
2) This may be Gnutella specific. Soulseek and BitTorrent both still work fine. I am not sure about other file sharing networks.
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 (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.
This is pretty sneaky actually, because Cox 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.
Sounds like Cox it attempting to have their cake and eat it too.
> At least you can download & you're trying to share...it's not your fault if your ISP are stopping that
Yeah, I sent a friend overseas a disc of things, and he put them in his file and shared them, so I was able to share in an indirect way.
Thanks for all your efforts.  |