Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? in Cox HSI

Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? in Cox HSI http://www.dslreports.com/forum/r19419052 en Sat, 22 Nov 2008 09:32:21 EDT Sat, 22 Nov 2008 09:32:21 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19490788 funchords : It's okay. It *IS* maddening! ]]> http://www.dslreports.com/forum/remark,19490788 Thu, 22 Nov 2007 10:31:57 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19490575 anon : Sorry about the last post, didn't mean to sound so rude about it. Im not mad at you, im pissed at cox.....]]> http://www.dslreports.com/forum/remark,19490575 Thu, 22 Nov 2007 09:40:07 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19490538 anon : My settings are fine. Every instance of my bit torrent connection has slowed down. And yes i know how Sandvine works, im not saying that Sandvine is responsible, but something definately is.

Also not to burst any bubble, but Sandvines tell tale behavior was "hot" on IRC about a month before it hit the news here. ]]> http://www.dslreports.com/forum/remark,19490538 Thu, 22 Nov 2007 09:31:44 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19489829 funchords :

said by ANON853 :

My bit torrent downloads have just recently slowed way way down.

It's possible, but unlikely, that Cox is throttling downloads. Make sure that your BitTorrent upload settings are set correctly. The wrong upload settings definitely affect your download speeds.

1. Take a speed test, note your upload speed in kb/s. (e.g. 248 kb/s)
2. Knock off the last digit to get the right upload speed limit in kB/s. (e.g. 24 kB/s) Set your upload speed limit to that number or less.
3. Wait 15 minutes after starting a download or after changing parameters for the protocol to find good reciprocating peers.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.]]> http://www.dslreports.com/forum/remark,19489829 Thu, 22 Nov 2007 02:25:17 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19489590 anon : Ok, this is bullshit. My bit torrent downloads have just recently slowed way way down. I hope dsl is available, if so i will be switching soon]]> http://www.dslreports.com/forum/remark,19489590 Thu, 22 Nov 2007 00:43:20 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19469174 MarkyD :

said by dvd536

said by MarkyD

:

I've given up on BitTorrent, and moved back to usenet. I'm seeing nearly 2MB/sec sustained speeds with usenet on my 12/1mbps Premier connection...better than advertised!
I'm seeing occasional boosts up over 3MB/sec!

You obviously aren't using cox's outsourced highwinds crapola if you're getting speeds like that :D

I think there was a node split in my neighborhood or something. Performance has increased by leaps and bounds over the last 2 weeks. No outages recently, and great performance...except with BitTorrent. Sigh.]]> http://www.dslreports.com/forum/remark,19469174 Sun, 18 Nov 2007 21:15:32 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19469138 dvd536 :

said by MarkyD

You obviously aren't using cox's outsourced highwinds crapola if you're getting speeds like that :D
--
You can never be too rich, too thin or have too much Bandwidth]]> http://www.dslreports.com/forum/remark,19469138 Sun, 18 Nov 2007 21:07:33 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19467811 MarkyD : I've given up on BitTorrent, and moved back to usenet. I'm seeing nearly 2MB/sec sustained speeds with usenet on my 12/1mbps Premier connection...better than advertised!
I'm seeing occasional boosts up over 3MB/sec!]]> http://www.dslreports.com/forum/remark,19467811 Sun, 18 Nov 2007 17:00:08 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19463894 robertfl : Again.. welcome to 1984.
I wonder what will happen when the masses dump cox as a result of this nonsense.

-Rob]]> http://www.dslreports.com/forum/remark,19463894 Sat, 17 Nov 2007 21:35:49 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19463619 funchords :

said by AnonHRCust :

I'm in Hampton Roads (Virginia Beach) and I can confirm that Cox filters P2P traffic here.

That sounds exactly like Sandvine.

I have had outside requests to gather more evidence. If you are familiar with Wireshark and either Gnutella, ED2K, and BitTorrent and can spend an hour or so with someone on the phone some evening, please write to me at robb(at-sign)funchords.com.

Thanks!
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.]]> http://www.dslreports.com/forum/remark,19463619 Sat, 17 Nov 2007 20:45:15 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19461384 anon : I'm in Hampton Roads (Virginia Beach) and I can confirm that Cox filters P2P traffic here. I noticed this with eMule a while ago, all the uploads would be killed instantly. I haven't used eMule in probably a year but I guess they're still doing it. BitTorrent seeding is also limited. Sometimes the connection will be killed instantly, other times I will be able to upload for about 30 seconds before the connection dies.]]> http://www.dslreports.com/forum/remark,19461384 Sat, 17 Nov 2007 12:15:42 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19460520 funchords : Good job jmccorm! You've broken their code! :) :D

said by Movieman420

:

At least Cox won't be accused of lying to and deceiving their customers.

True to a point, but Cox's forging a packet header to make it appear as if your peer has "hung up on you" is still lying and deceiving.

This is arrogance on their part. In 2005, the industry promised the FCC that they wouldn't do stuff like this. In return, the FCC didn't impose Net Neutrality rules on them, saying that there wasn't any evidence that any were needed.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.]]> http://www.dslreports.com/forum/remark,19460520 Sat, 17 Nov 2007 07:29:01 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19459515 Movieman420 : At least they're admitting that they do filter protocols and that's WAY more than Comcast's PR will admit.

No doubt in my mind, Cox will be joining Comcast in the FCC complaints and class action law suits. At least Cox won't be accused of lying to and deceiving their customers. ]]> http://www.dslreports.com/forum/remark,19459515 Fri, 16 Nov 2007 22:53:02 EDT Re: (update) Cox Manager: Cox Confirms They Use Protocol Filteri http://www.dslreports.com/forum/remark,19459358 jmccorm : PR TRANSLATION FOLLOWS:

Cox actively manages network traffic through a variety of methods including traffic prioritization and protocol filtering.

"We do some things. Here are a few examples that I want to throw out there. This isn't the whole list, though."

Cox does not prohibit the use of file-sharing services for uploads or downloads.

"We do not outright *stop* (through technology or policy) the use of file-sharing services on our network."

(Cox does not) discriminate against any specific services in any way.

ERROR. ERROR. Inconsistency detected. You just got through saying that "Cox actively managers network traffic through a variety of methods including ... protocol filtering." If that isn't discriminating against any specific service, what is?

To help our customers make the most out of their Internet experience, we take proactive measures to ensure that bandwidth intensive applications do not negatively impact their service.

"We take proactive measures against bandwidth intensive applications, but we won't go into any detail about what that means." "But we degrade a user's service in order not to negatively impact their service. We have to kill the citizens in order to save them."

These network management practices are outlined in our subscriber agreement and Acceptable Use Policy.

"Please refer to this generic document which doesn't answer the question in any more detail."]]> http://www.dslreports.com/forum/remark,19459358 Fri, 16 Nov 2007 22:22:03 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19459308 ZaRRaZa : i dont know boi... i been tryin to find out that forever with no success... lol

I been usin cox for 4 years, my parents for 6, and i would stay with cox if they would offer more upstream... but now the difference between cox and fios is so huge... that if i'll have a chance to switch to fios... I WILL...

u know its hard to leave cox... cuz i was gettin very good service all the time. Had only 1-2 issues for all the time i been with cox... but u kno they cant keep up with fios. I read somewhere in this forum that cox gonna update up speedz to 4 mbps only by 2010.... thats ridiculous, because by that time fios gonna be offering 1000/1000 or so to home users.... lol.

Only strongest survives... ]]> http://www.dslreports.com/forum/remark,19459308 Fri, 16 Nov 2007 22:11:25 EDT (update) Cox Manager: Cox Confirms They Use Protocol Filtering http://www.dslreports.com/forum/remark,19459286 funchords : From Cox's David Deliman, Product Communications Manager:

To ensure the best possible online experience for our customers, Cox actively manages network traffic through a variety of methods including traffic prioritization and protocol filtering. Cox does not prohibit the use of file-sharing services for uploads or downloads, or discriminate against any specific services in any way. To help our customers make the most out of their Internet experience, we take proactive measures to ensure that bandwidth intensive applications do not negatively impact their service. These network management practices are outlined in our subscriber agreement and Acceptable Use Policy.

»Cox Also Disrupting P2P Traffic
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.]]> http://www.dslreports.com/forum/remark,19459286 Fri, 16 Nov 2007 22:08:04 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19459236 dvd536 :

said by ZaRRaZa

:

That split between down and up is ridiculous (20/2)

Some of us are only getting 12/1.
with 2 up you must be in a fios area. is fios available to you?
--
You can never be too rich, too thin or have too much Bandwidth]]> http://www.dslreports.com/forum/remark,19459236 Fri, 16 Nov 2007 21:57:05 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19454243 Plasticman : An answer to your question if they are interferring:

»Cox Also Disrupting P2P Traffic

Story posted yesterday and they had Robb check it out....

Plasticman]]> http://www.dslreports.com/forum/remark,19454243 Fri, 16 Nov 2007 06:30:18 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19453803 ZaRRaZa : just want to say... been using cox for 4 years now. I get constant 1.5-2.0 MB/s down and 150-200 KB/s up (at night time reaches 250 KB/s) from private torrents.
Down record for few secs is 2.9 MB/s ... and constant 2.5 MB/s for few minz. And im positive that i went over 60 GB at least once and 15 GB upload a lot. I would say my down record is 100-150 GB a month and about 50GB upload. Never received a letter. So far cox is really nice. The one negative thing is that they need to increase up speeds. That split between down and up is ridiculous (20/2).

cya ]]> http://www.dslreports.com/forum/remark,19453803 Fri, 16 Nov 2007 01:50:28 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19453047 wierdo : Funny, my tests between my server in SD and my line in Tulsa seem to be showing a 100% inability to act as a seed for either. The route between the two is 100% Cox.

jshort was kind enough to offer his help and we found that I can seed from my CBS line in Arkansas, but not from CBS in San Diego, nor from my residential line in Tulsa. They've apparently not gotten around to installing the filters in the Kansas market yet.

It appears Cox is doing their best to block seeding 100%, even on CBS lines.

Now I'm angry. As I mentioned earlier, seeding from a residential line is, strictly speaking, a contravention of the TOS we all agree to. By contract, I should be able to seed all I want on the CBS lines, but cannot.]]> http://www.dslreports.com/forum/remark,19453047 Thu, 15 Nov 2007 22:42:51 EDT Re: Here's Proof: Cox Interferes with P2P Uploads http://www.dslreports.com/forum/remark,19452951 funchords :

said by wierdo

:

Maybe I'm just misremembering, but IIRC sending an RST is the correct behavior when an endpoint [including a NAT device] receives a TCP packet that appears to be referring to a nonexistent connection.

Well, you'll have to take that up with the BEHAVE Working Group of the IETF.

Meanwhile, the RSTs in this case are definitely not caused by NAT devices, so the matter is academic only.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.]]> http://www.dslreports.com/forum/remark,19452951 Thu, 15 Nov 2007 22:30:33 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19452883 jmccorm : UPDATE: It looks like Cox has been tweaking their parameters since my initial complaint on Sunday. (Sitting at 0kB/s for very long periods of time.) I am still noticing some interference with my upload stream. But I'm able to reach and mostly sustain up to my self-imposed cap for stretches of a few minutes at a time. (Even if my uploads get to a sputtering start at first.)

Compared to Sunday, it looks like it is now probably operating more with the intent that they were shooting for, which would be to occasionally disrupt off-net upload streams in order to give on-net connections a chance to take hold. My upstream bandwidth gets torn down here and there, by varying amounts and at semi-random intervals (as far as I can tell).

Not that this doesn't still break networking standards. User funchords' definition of 'abuse' covers that well enough.]]> http://www.dslreports.com/forum/remark,19452883 Thu, 15 Nov 2007 22:21:52 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19452788 jsouth : I usually max out my lines with Azureus. I'm in Wichita.
--
Bush bashing is old. How about more solutions instead?]]> http://www.dslreports.com/forum/remark,19452788 Thu, 15 Nov 2007 22:08:19 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19452742 wierdo : Just FWIW, I can confirm 100% absolutely that something in Cox's network is sending these spurious RST packets. ;)

I'll report back after I test a few other modes of operation besides my home connection as a server. (which Cox could rightly block, given the TOS forbidding servers)

Can anyone confirm this behavior on Cox's network in the Kansas market? (I have a CBS line in that market, while my line in the Oklahoma market is residential)

Edited to add: They also appear to be doing this intra network. I have a server in San Diego that, among other upstreams, has fiber to CBS. Using that server as a seed to my home network also appears to be generating the same behavior. IMO, that's far more insidious.]]> http://www.dslreports.com/forum/remark,19452742 Thu, 15 Nov 2007 22:01:37 EDT Re: Here's Proof: Cox Interferes with P2P Uploads http://www.dslreports.com/forum/remark,19452683 robertfl : comcast is being sued. is cox next?

If all we will be able to do on or any service is surf the web and check e-mail, then i'm going back to dial up. no need to cough up $50+ dollars for "censored" internet.

Again, they need to stop adverizing "download movies and music at blazing speeds"

-Rob ]]> http://www.dslreports.com/forum/remark,19452683 Thu, 15 Nov 2007 21:51:16 EDT Re: Here's Proof: Cox Interferes with P2P Uploads http://www.dslreports.com/forum/remark,19452610 wierdo :

said by funchords

:

]Great question. According to the BEHAVE IETF Working Group, NAT devices should send an ICMP unreachable error and/or drop the packet in that case.

In this case, however, the RST is following an exact pattern that repeats. With the SYN long past, and a data packet received less than 100 ms. ago, there's no valid reason a remote peer should generate a reset.

This is clearly interference, it matches the Comcast eDonkey interference.

Maybe I'm just misremembering, but IIRC sending an RST is the correct behavior when an endpoint receives a TCP packet that appears to be referring to a nonexistent connection.

Specifically, when a TCP packet is received that does not have the SYN or FIN bit set.

We mustn't forget that devices that happen to do NAT are also endpoints in their own right and thus must conform to standard behavior when they receive a packet appearing to belong to a connection that does not exist.

Silent dropping is a common behavior, but is not, strictly speaking, correct. Sending an ICMP port unreachable is the correct response when receiving a packet with the SYN bit set which has a destination port which is not valid for the receiving host.

What will happen (and this is incorrect behavior) if a router running Linux runs out of NAT table space is exactly what you describe. The peer sends packets just fine, but when we send one back, the NAT router sends back an RST because it sees our packet as invalid.

Again, I'm not at all arguing that Cox is not testing some dumb as paint device that does what you claim, I'm just pointing out that the same things can be explained by things that have nothing to do with Cox. In fact, I wouldn't be surprised if a good number of BT users had that exact problem due to poor NAT devices at the remote end.

What I don't get is why on earth any ISP would use such blatantly idiotic technology when they could just as easily use similar deep packet inspection to mark BT and other bulk traffic as such and use standard QoS to delay (or deprioritize) packets so marked. Doing it that way would achieve the same ends, but in a way that would be completely impossible to prove was actually happening, so long as the mark was removed before the packet exited Cox's network.]]> http://www.dslreports.com/forum/remark,19452610 Thu, 15 Nov 2007 21:39:59 EDT Re: Here's Proof: Cox Interferes with P2P Uploads http://www.dslreports.com/forum/remark,19451401 funchords :

said by kingofdsl

:

How is it abuse when Cox owns the network?

Answered here:
»My use of the word 'Abuse']]> http://www.dslreports.com/forum/remark,19451401 Thu, 15 Nov 2007 18:49:51 EDT Re: Here's Proof: Cox Interferes with P2P Uploads http://www.dslreports.com/forum/remark,19451393 funchords :

said by wierdo

:

I'm not saying this is what's happening in this particular case, but there do exist broken NAT devices that lose track of NAT mappings when being beaten on by a BT client and thus send an RST when they receive an "unexpected" (only unexpected because the NAT table filled up, of course) packet.

Great question. According to the BEHAVE IETF Working Group, NAT devices should send an ICMP unreachable error and/or drop the packet in that case.

In this case, however, the RST is following an exact pattern that repeats. With the SYN long past, and a data packet received less than 100 ms. ago, there's no valid reason a remote peer should generate a reset.

This is clearly interference, it matches the Comcast eDonkey interference.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.]]> http://www.dslreports.com/forum/remark,19451393 Thu, 15 Nov 2007 18:47:15 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19451231 kabhal : I came to Cox from AT&T because Cox had a faster tier. 12000/1000; with at&t the highest I had was 6016/768 - but the connection was rock solid and worked great with at&t, web/torrents/usenet/ftp/gaming whatever. So no problems with that, they just didn't have the fastest speed.

I haven't tried torrents much yet with my new Cox 12000/1000 so I don't know about any "interferance", but my newsgroup downloads are fantastic. =) Unbelievably fast. I use giganews/newzbin/and newsleecher and my god, it's like night and day speedwise vs AT&T. Really great speeds. I'm really happy with it (had it for about month and half now) so I hope they don't start limiting/degrading usenet access like they are doing with torrents. :p]]> http://www.dslreports.com/forum/remark,19451231 Thu, 15 Nov 2007 18:20:31 EDT Re: Here's Proof: Cox Interferes with P2P Uploads http://www.dslreports.com/forum/remark,19450985 robertfl : Welcome to 1984. I think other ISP's will follow suit as well.

-Rob]]> http://www.dslreports.com/forum/remark,19450985 Thu, 15 Nov 2007 17:42:12 EDT Re: Here's Proof: Cox Interferes with P2P Uploads http://www.dslreports.com/forum/remark,19450878 wierdo : I'm not saying this is what's happening in this particular case, but there do exist broken NAT devices that lose track of NAT mappings when being beaten on by a BT client and thus send an RST when they receive an "unexpected" (only unexpected because the NAT table filled up, of course) packet.

RSTs are not in and of themselves abnormal with broken NAT devices or broken end user machines. NAT tables filling and a crash of the BT client at the far end can both cause the OS itself (either on the NAT device or the endpoint) to send said RST.

Edited to add: To be clear, RSTs are perfectly normal when one end thinks there is a TCP connection in progress and the other end doesn't. That's how TCP deals with such a state mismatch.]]> http://www.dslreports.com/forum/remark,19450878 Thu, 15 Nov 2007 17:24:52 EDT Re: Here's Proof: Cox Interferes with P2P Uploads http://www.dslreports.com/forum/remark,19450532 kingofdsl : This is conclusive proof that Cox is interfering with eDonkey uploads by abusing the RST (abort/reset) flag.

--Robb Topolski
=======================================================
How is it abuse when Cox owns the network?]]> http://www.dslreports.com/forum/remark,19450532 Thu, 15 Nov 2007 16:20:46 EDT Here's Proof: Cox Interferes with P2P Uploads http://www.dslreports.com/forum/remark,19449983 funchords : Excellent, Tsume! This is the same behavior seen on Comcast with Sandvine's interference with many of the P2P protocols.

The following capture was on the eDonkey network between a Cox user and a user in Tel-Aviv, Israel. In this exchange, the non-Cox user connects, handshakes, and then requests parts, at which time the connection is immediately disrupted by an abort signal (TCP flag RST). The same pattern is repeated for all download requests.

No.     Time        Source                Destination           Protocol Info      1 0.000000    88.154.XXX.XXX           COX.COX.COX.COX         TCP      3803 > 57909 [SYN] Seq=0 Len=0 MSS=1432 Frame 1 (62 bytes on wire, 62 bytes captured)Ethernet II, Src: D-Link_5f:XX:XX (00:19:5b:5f:XX:XX), Dst: Elitegro_3c:XX:XX (00:19:21:3c:XX:XX)Internet Protocol, Src: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net), Dst: YYY.YYY.YYY.YYY (cox.net)    Version: 4    Header length: 20 bytes    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)    Total Length: 48    Identification: 0xf2ed (62189)    Flags: 0x04 (Don't Fragment)    Fragment offset: 0    Time to live: 114    Protocol: TCP (0x06)    Header checksum: 0xf18b [correct]    Source: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net)    Destination: YYY.YYY.YYY.YYY (cox.net)Transmission Control Protocol, Src Port: 3803 (3803), Dst Port: 57909 (57909), Seq: 0, Len: 0 No.     Time        Source                Destination           Protocol Info      2 3.530691    88.154.XXX.XXX           COX.COX.COX.COX         TCP      3803 > 57909 [SYN] Seq=0 Len=0 MSS=1432 Frame 2 (62 bytes on wire, 62 bytes captured)Ethernet II, Src: D-Link_5f:XX:XX (00:19:5b:5f:XX:XX), Dst: Elitegro_3c:XX:XX (00:19:21:3c:XX:XX)Internet Protocol, Src: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net), Dst: YYY.YYY.YYY.YYY (cox.net)    Version: 4    Header length: 20 bytes    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)    Total Length: 48    Identification: 0xf359 (62297)    Flags: 0x04 (Don't Fragment)    Fragment offset: 0    Time to live: 114    Protocol: TCP (0x06)    Header checksum: 0xf11f [correct]    Source: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net)    Destination: YYY.YYY.YYY.YYY (cox.net)Transmission Control Protocol, Src Port: 3803 (3803), Dst Port: 57909 (57909), Seq: 0, Len: 0 No.     Time        Source                Destination           Protocol Info      3 3.845140    88.154.XXX.XXX           COX.COX.COX.COX         TCP      3803 > 57909 [ACK] Seq=1 Ack=0 Win=65535 Len=0 Frame 3 (60 bytes on wire, 60 bytes captured)Ethernet II, Src: D-Link_5f:XX:XX (00:19:5b:5f:XX:XX), Dst: Elitegro_3c:XX:XX (00:19:21:3c:XX:XX)Internet Protocol, Src: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net), Dst: YYY.YYY.YYY.YYY (cox.net)    Version: 4    Header length: 20 bytes    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)    Total Length: 40    Identification: 0xf365 (62309)    Flags: 0x04 (Don't Fragment)    Fragment offset: 0    Time to live: 114    Protocol: TCP (0x06)    Header checksum: 0xf11b [correct]    Source: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net)    Destination: YYY.YYY.YYY.YYY (cox.net)Transmission Control Protocol, Src Port: 3803 (3803), Dst Port: 57909 (57909), Seq: 1, Ack: 0, Len: 0 No.     Time        Source                Destination           Protocol Info      4 3.865210    88.154.XXX.XXX           COX.COX.COX.COX         eDonkey  eDonkey TCP: Hello Frame 4 (191 bytes on wire, 191 bytes captured)Ethernet II, Src: D-Link_5f:XX:XX (00:19:5b:5f:XX:XX), Dst: Elitegro_3c:XX:XX (00:19:21:3c:XX:XX)Internet Protocol, Src: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net), Dst: YYY.YYY.YYY.YYY (cox.net)    Version: 4    Header length: 20 bytes    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)    Total Length: 177    Identification: 0xf367 (62311)    Flags: 0x04 (Don't Fragment)    Fragment offset: 0    Time to live: 114    Protocol: TCP (0x06)    Header checksum: 0xf090 [correct]    Source: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net)    Destination: YYY.YYY.YYY.YYY (cox.net)Transmission Control Protocol, Src Port: 3803 (3803), Dst Port: 57909 (57909), Seq: 1, Ack: 0, Len: 137eDonkey Protocol No.     Time        Source                Destination           Protocol Info      5 6.892877    88.154.XXX.XXX           COX.COX.COX.COX         TCP      [TCP Dup ACK 4#1] 3803 > 57909 [ACK] Seq=138 Ack=0 Win=65535 Len=0 Frame 5 (60 bytes on wire, 60 bytes captured)Ethernet II, Src: D-Link_5f:XX:XX (00:19:5b:5f:XX:XX), Dst: Elitegro_3c:XX:XX (00:19:21:3c:XX:XX)Internet Protocol, Src: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net), Dst: YYY.YYY.YYY.YYY (cox.net)    Version: 4    Header length: 20 bytes    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)    Total Length: 40    Identification: 0xf3ce (62414)    Flags: 0x04 (Don't Fragment)    Fragment offset: 0    Time to live: 114    Protocol: TCP (0x06)    Header checksum: 0xf0b2 [correct]    Source: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net)    Destination: YYY.YYY.YYY.YYY (cox.net)Transmission Control Protocol, Src Port: 3803 (3803), Dst Port: 57909 (57909), Seq: 138, Ack: 0, Len: 0 No.     Time        Source                Destination           Protocol Info      6 7.857685    88.154.XXX.XXX           COX.COX.COX.COX         eDonkey  eDonkey TCP: File Request Frame 6 (83 bytes on wire, 83 bytes captured)Ethernet II, Src: D-Link_5f:XX:XX (00:19:5b:5f:XX:XX), Dst: Elitegro_3c:XX:XX (00:19:21:3c:XX:XX)Internet Protocol, Src: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net), Dst: YYY.YYY.YYY.YYY (cox.net)    Version: 4    Header length: 20 bytes    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)    Total Length: 69    Identification: 0xf3ec (62444)    Flags: 0x04 (Don't Fragment)    Fragment offset: 0    Time to live: 114    Protocol: TCP (0x06)    Header checksum: 0xf077 [correct]    Source: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net)    Destination: YYY.YYY.YYY.YYY (cox.net)Transmission Control Protocol, Src Port: 3803 (3803), Dst Port: 57909 (57909), Seq: 138, Ack: 109, Len: 29eDonkey Protocol No.     Time        Source                Destination           Protocol Info      7 10.851679   88.154.XXX.XXX           COX.COX.COX.COX         TCP      [TCP Dup ACK 6#1] 3803 > 57909 [ACK] Seq=167 Ack=109 Win=65426 Len=0 Frame 7 (60 bytes on wire, 60 bytes captured)Ethernet II, Src: D-Link_5f:XX:XX (00:19:5b:5f:XX:XX), Dst: Elitegro_3c:XX:XX (00:19:21:3c:XX:XX)Internet Protocol, Src: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net), Dst: YYY.YYY.YYY.YYY (cox.net)    Version: 4    Header length: 20 bytes    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)    Total Length: 40    Identification: 0xf439 (62521)    Flags: 0x04 (Don't Fragment)    Fragment offset: 0    Time to live: 114    Protocol: TCP (0x06)    Header checksum: 0xf047 [correct]    Source: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net)    Destination: YYY.YYY.YYY.YYY (cox.net)Transmission Control Protocol, Src Port: 3803 (3803), Dst Port: 57909 (57909), Seq: 167, Ack: 109, Len: 0 No.     Time        Source                Destination           Protocol Info      8 11.997924   88.154.XXX.XXX           COX.COX.COX.COX         eDonkey  eDonkey TCP: File Status Request Frame 8 (76 bytes on wire, 76 bytes captured)Ethernet II, Src: D-Link_5f:XX:XX (00:19:5b:5f:XX:XX), Dst: Elitegro_3c:XX:XX (00:19:21:3c:XX:XX)Internet Protocol, Src: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net), Dst: YYY.YYY.YYY.YYY (cox.net)    Version: 4    Header length: 20 bytes    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)    Total Length: 62    Identification: 0xf44f (62543)    Flags: 0x04 (Don't Fragment)    Fragment offset: 0    Time to live: 114    Protocol: TCP (0x06)    Header checksum: 0xf01b [correct]    Source: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net)    Destination: YYY.YYY.YYY.YYY (cox.net)Transmission Control Protocol, Src Port: 3803 (3803), Dst Port: 57909 (57909), Seq: 167, Ack: 173, Len: 22eDonkey Protocol No.     Time        Source                Destination           Protocol Info      9 16.089054   88.154.XXX.XXX           COX.COX.COX.COX         eDonkey  eDonkey TCP: Slot Request Frame 9 (76 bytes on wire, 76 bytes captured)Ethernet II, Src: D-Link_5f:XX:XX (00:19:5b:5f:XX:XX), Dst: Elitegro_3c:XX:XX (00:19:21:3c:XX:XX)Internet Protocol, Src: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net), Dst: YYY.YYY.YYY.YYY (cox.net)    Version: 4    Header length: 20 bytes    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)    Total Length: 62    Identification: 0xf4c3 (62659)    Flags: 0x04 (Don't Fragment)    Fragment offset: 0    Time to live: 114    Protocol: TCP (0x06)    Header checksum: 0xefa7 [correct]    Source: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net)    Destination: YYY.YYY.YYY.YYY (cox.net)Transmission Control Protocol, Src Port: 3803 (3803), Dst Port: 57909 (57909), Seq: 189, Ack: 198, Len: 22eDonkey Protocol No.     Time        Source                Destination           Protocol Info     10 20.428610   88.154.XXX.XXX           COX.COX.COX.COX         eDonkey  eDonkey TCP: Request Parts Frame 10 (100 bytes on wire, 100 bytes captured)Ethernet II, Src: D-Link_5f:XX:XX (00:19:5b:5f:XX:XX), Dst: Elitegro_3c:XX:XX (00:19:21:3c:XX:XX)Internet Protocol, Src: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net), Dst: YYY.YYY.YYY.YYY (cox.net)    Version: 4    Header length: 20 bytes    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)    Total Length: 86    Identification: 0xf52b (62763)    Flags: 0x04 (Don't Fragment)    Fragment offset: 0    Time to live: 114    Protocol: TCP (0x06)    Header checksum: 0xef27 [correct]    Source: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net)    Destination: YYY.YYY.YYY.YYY (cox.net)Transmission Control Protocol, Src Port: 3803 (3803), Dst Port: 57909 (57909), Seq: 211, Ack: 204, Len: 46eDonkey Protocol No.     Time        Source                Destination           Protocol Info     11 20.429537   88.154.XXX.XXX           COX.COX.COX.COX         TCP      3803 > 57909 [RST] Seq=257 Len=0 Frame 11 (60 bytes on wire, 60 bytes captured)Ethernet II, Src: D-Link_5f:XX:XX (00:19:5b:5f:XX:XX), Dst: Elitegro_3c:XX:XX (00:19:21:3c:XX:XX)Internet Protocol, Src: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net), Dst: YYY.YYY.YYY.YYY (cox.net)    Version: 4    Header length: 20 bytes    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)    Total Length: 40    Identification: 0xf52f (62767)    Flags: 0x00    Fragment offset: 0    Time to live: 113    Protocol: TCP (0x06)    Header checksum: 0x3052 [correct]    Source: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net)    Destination: YYY.YYY.YYY.YYY (cox.net)Transmission Control Protocol, Src Port: 3803 (3803), Dst Port: 57909 (57909), Seq: 257, Len: 0 No.     Time        Source                Destination           Protocol Info     12 20.429719   88.154.XXX.XXX           COX.COX.COX.COX         TCP      3803 > 57909 [RST] Seq=12760 Len=0 Frame 12 (60 bytes on wire, 60 bytes captured)Ethernet II, Src: D-Link_5f:XX:XX (00:19:5b:5f:XX:XX), Dst: Elitegro_3c:XX:XX (00:19:21:3c:XX:XX)Internet Protocol, Src: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net), Dst: YYY.YYY.YYY.YYY (cox.net)    Version: 4    Header length: 20 bytes    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)    Total Length: 40    Identification: 0xf530 (62768)    Flags: 0x00    Fragment offset: 0    Time to live: 113    Protocol: TCP (0x06)    Header checksum: 0x3051 [correct]    Source: 88.154.XXX.XXX (bzq-88-154-XXX-XXX.red.bezeqint.net)    Destination: YYY.YYY.YYY.YYY (cox.net)Transmission Control Protocol, Src Port: 3803 (3803), Dst Port: 57909 (57909), Seq: 12760, Len: 0

Here are the other attempts from peers attempting to download from a peer using Cox:

No.     Time        Source                Destination           Protocol Info     13 46.586053   24.189.31.XXX         COX.COX.COX.COX       TCP      2812 > 57909 [SYN] Seq=0 Len=0 MSS=1260     14 46.687668   24.189.31.XXX         COX.COX.COX.COX       TCP      2812 > 57909 [ACK] Seq=1 Ack=0 Win=65535 Len=0     15 46.748282   24.189.31.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello     16 47.024208   24.189.31.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: File Request     17 47.134846   24.189.31.XXX         COX.COX.COX.COX       eDonkey  eMule Extensions TCP: Sources Request     18 47.298049   24.189.31.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request     19 47.562492   24.189.31.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts     20 47.563020   24.189.31.XXX         COX.COX.COX.COX       TCP      2812 > 57909 [RST] Seq=292 Len=0     21 47.563022   24.189.31.XXX         COX.COX.COX.COX       TCP      2812 > 57909 [RST] Seq=12795 Len=0      22 65.136343   24.185.8.XXX          COX.COX.COX.COX       TCP      62534 > 57909 [SYN] Seq=0 Len=0 MSS=1460     23 65.247461   24.185.8.XXX          COX.COX.COX.COX       TCP      62534 > 57909 [ACK] Seq=1 Ack=0 Win=17520 Len=0     24 65.310605   24.185.8.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello     25 65.572995   24.185.8.XXX          COX.COX.COX.COX       TCP      62534 > 57909 [ACK] Seq=110 Ack=109 Win=17411 Len=0     26 65.634605   24.185.8.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: File Request     27 65.771306   24.185.8.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: File Status Request     28 65.950557   24.185.8.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request     29 66.112815   24.185.8.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts     30 66.113299   24.185.8.XXX          COX.COX.COX.COX       TCP      62534 > 57909 [RST] Seq=229 Len=0     31 66.113468   24.185.8.XXX          COX.COX.COX.COX       TCP      62534 > 57909 [RST] Seq=12732 Len=0      32 67.254090   82.166.149.XXX        COX.COX.COX.COX       TCP      1993 > 57909 [SYN] Seq=0 Len=0 MSS=1452     33 67.514098   82.166.149.XXX        COX.COX.COX.COX       TCP      1993 > 57909 [ACK] Seq=1 Ack=0 Win=65535 Len=0     34 67.603107   82.166.149.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello     35 68.037685   82.166.149.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: File Request     36 68.339129   82.166.149.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: File Status Request     37 68.687124   82.166.149.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request     38 70.924634   82.166.149.XXX        COX.COX.COX.COX       eDonkey  [TCP Retransmission] eDonkey TCP: Slot Request     39 71.672143   82.166.149.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts     40 71.672770   82.166.149.XXX        COX.COX.COX.COX       TCP      1993 > 57909 [RST] Seq=264 Len=0     41 71.672773   82.166.149.XXX        COX.COX.COX.COX       TCP      1993 > 57909 [RST] Seq=12767 Len=0     43 71.917529   82.166.149.XXX        COX.COX.COX.COX       TCP      1993 > 57909 [ACK] Seq=264 Ack=199 Win=65336 Len=0     44 71.917711   82.166.149.XXX        COX.COX.COX.COX       TCP      1993 > 57909 [RST] Seq=264 Len=0     45 71.917859   82.166.149.XXX        COX.COX.COX.COX       TCP      1993 > 57909 [RST] Seq=12767 Len=0      42 71.860454   91.146.240.XXX        COX.COX.COX.COX       TCP      1621 > 57909 [SYN] Seq=0 Len=0 MSS=1460     46 72.060726   91.146.240.XXX        COX.COX.COX.COX       TCP      1621 > 57909 [ACK] Seq=1 Ack=0 Win=65535 Len=0     47 72.067227   91.146.240.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello     49 73.352168   91.146.240.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: File Request     50 73.567989   91.146.240.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: File Status Request     51 73.816861   91.146.240.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request     52 74.047680   91.146.240.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts     53 74.048650   91.146.240.XXX        COX.COX.COX.COX       TCP      1621 > 57909 [RST] Seq=226 Len=0     54 74.048821   91.146.240.XXX        COX.COX.COX.COX       TCP      1621 > 57909 [RST] Seq=12729 Len=0      48 73.090273   87.69.104.XXX         COX.COX.COX.COX       TCP      3354 > 57909 [SYN] Seq=0 Len=0 MSS=1360     55 75.245499   87.69.104.XXX         COX.COX.COX.COX       TCP      3354 > 57909 [ACK] Seq=1 Ack=0 Win=65535 Len=0     56 75.249467   87.69.104.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello     57 81.775774   87.69.104.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: File Request     58 83.698172   87.69.104.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: File Status Request     59 85.681663   87.69.104.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request     60 87.415781   87.69.104.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts     61 87.416247   87.69.104.XXX         COX.COX.COX.COX       TCP      3354 > 57909 [RST] Seq=213 Len=0     62 87.416944   87.69.104.XXX         COX.COX.COX.COX       TCP      3354 > 57909 [RST] Seq=12716 Len=0     63 94.871840   87.69.104.XXX         COX.COX.COX.COX       eDonkey  [TCP Retransmission] eDonkey TCP: Request Parts      64 103.397576  58.173.104.XXX        COX.COX.COX.COX       TCP      4010 > 57909 [SYN] Seq=0 Len=0 MSS=1460     65 103.603587  58.173.104.XXX        COX.COX.COX.COX       TCP      4010 > 57909 [ACK] Seq=1 Ack=0 Win=17520 Len=0     66 103.822975  58.173.104.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello     67 104.243129  58.173.104.XXX        COX.COX.COX.COX       eDonkey  eMule Extensions TCP: Sources Request     68 104.590641  58.173.104.XXX        COX.COX.COX.COX       TCP      4010 > 57909 [ACK] Seq=209 Ack=173 Win=17347 Len=0     69 104.961175  58.173.104.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request     70 105.287189  58.173.104.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts     71 105.288143  58.173.104.XXX        COX.COX.COX.COX       TCP      4010 > 57909 [RST] Seq=277 Len=0     72 105.288329  58.173.104.XXX        COX.COX.COX.COX       TCP      4010 > 57909 [RST] Seq=12780 Len=0      86 196.968087  99.194.169.XXX        COX.COX.COX.COX       TCP      4124 > 57909 [SYN] Seq=0 Len=0 MSS=1460     87 197.068221  99.194.169.XXX        COX.COX.COX.COX       TCP      4124 > 57909 [ACK] Seq=1 Ack=0 Win=65535 Len=0     88 197.289546  99.194.169.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello     89 197.608485  99.194.169.XXX        COX.COX.COX.COX       TCP      4124 > 57909 [ACK] Seq=93 Ack=109 Win=65426 Len=0     90 197.738713  99.194.169.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: File Request     91 197.828346  99.194.169.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: File Status Request     92 198.120301  99.194.169.XXX        COX.COX.COX.COX       TCP      4124 > 57909 [ACK] Seq=144 Ack=198 Win=65337 Len=0     93 198.162843  99.194.169.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request     94 198.353632  99.194.169.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts     95 198.354607  99.194.169.XXX        COX.COX.COX.COX       TCP      4124 > 57909 [RST] Seq=212 Len=0     96 198.354778  99.194.169.XXX        COX.COX.COX.COX       TCP      4124 > 57909 [RST] Seq=12715 Len=0     97 198.461288  99.194.169.XXX        COX.COX.COX.COX       TCP      4124 > 57909 [ACK] Seq=212 Ack=204 Win=65331 Len=0     98 198.461471  99.194.169.XXX        COX.COX.COX.COX       TCP      4124 > 57909 [RST] Seq=212 Len=0     99 198.461621  99.194.169.XXX        COX.COX.COX.COX       TCP      4124 > 57909 [RST] Seq=12715 Len=0      79 184.539926  87.70.91.XXX          COX.COX.COX.COX       TCP      2247 > 57909 [SYN] Seq=0 Len=0 MSS=1360     80 185.267027  87.70.91.XXX          COX.COX.COX.COX       TCP      2247 > 57909 [ACK] Seq=1 Ack=0 Win=65535 Len=0     81 188.257524  87.70.91.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello     83 192.171362  87.70.91.XXX          COX.COX.COX.COX       eDonkey  eMule Extensions TCP: Unknown     84 192.802313  87.70.91.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: File Status Request     85 193.323101  87.70.91.XXX          COX.COX.COX.COX       TCP      2247 > 57909 [ACK] Seq=199 Ack=168 Win=65367 Len=0    100 198.840396  87.70.91.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request    101 200.734723  87.70.91.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts    102 200.735666  87.70.91.XXX          COX.COX.COX.COX       TCP      2247 > 57909 [RST] Seq=267 Len=0    103 200.735830  87.70.91.XXX          COX.COX.COX.COX       TCP      2247 > 57909 [RST] Seq=12770 Len=0     107 308.003628  201.73.192.XXX        COX.COX.COX.COX       TCP      1938 > 57909 [SYN] Seq=0 Len=0 MSS=1460    108 308.277002  201.73.192.XXX        COX.COX.COX.COX       TCP      1938 > 57909 [ACK] Seq=1 Ack=0 Win=65535 Len=0    109 308.467273  201.73.192.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello    110 308.818803  201.73.192.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: File Request    111 309.080137  201.73.192.XXX        COX.COX.COX.COX       eDonkey  eMule Extensions TCP: Sources Request    112 309.560379  201.73.192.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request    113 309.894915  201.73.192.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts    114 309.895386  201.73.192.XXX        COX.COX.COX.COX       TCP      1938 > 57909 [RST] Seq=227 Len=0    115 309.895565  201.73.192.XXX        COX.COX.COX.COX       TCP      1938 > 57909 [RST] Seq=12730 Len=0     116 322.167835  201.78.174.XXX        COX.COX.COX.COX       TCP      4446 > 57909 [SYN] Seq=0 Len=0 MSS=1440    117 322.454974  201.78.174.XXX        COX.COX.COX.COX       TCP      4446 > 57909 [ACK] Seq=1 Ack=0 Win=65535 Len=0    118 322.471262  201.78.174.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello    119 322.781271  201.78.174.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: File Request    120 323.085480  201.78.174.XXX        COX.COX.COX.COX       eDonkey  eMule Extensions TCP: Sources Request    121 323.574505  201.78.174.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request    122 323.864419  201.78.174.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts    123 323.865082  201.78.174.XXX        COX.COX.COX.COX       TCP      4446 > 57909 [RST] Seq=227 Len=0    124 323.865084  201.78.174.XXX        COX.COX.COX.COX       TCP      4446 > 57909 [RST] Seq=12730 Len=0     125 339.226952  71.105.61.XXX         COX.COX.COX.COX       TCP      1913 > 57909 [SYN] Seq=0 Len=0 MSS=1460    126 340.758729  71.105.61.XXX         COX.COX.COX.COX       TCP      1913 > 57909 [ACK] Seq=1 Ack=0 Win=65535 Len=0    127 340.780293  71.105.61.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello    128 342.468313  71.105.61.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: File Request    129 344.260537  71.105.61.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: File Status Request    130 345.916531  71.105.61.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request    131 347.318155  71.105.61.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts    132 347.319075  71.105.61.XXX         COX.COX.COX.COX       TCP      1913 > 57909 [RST] Seq=211 Len=0    133 347.319242  71.105.61.XXX         COX.COX.COX.COX       TCP      1913 > 57909 [RST] Seq=12714 Len=0     134 358.192466  91.185.118.XXX        COX.COX.COX.COX       TCP      4439 > 57909 [SYN] Seq=0 Len=0 MSS=1460    135 358.646150  91.185.118.XXX        COX.COX.COX.COX       TCP      4439 > 57909 [ACK] Seq=1 Ack=0 Win=17520 Len=0    136 359.183435  91.185.118.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello    137 360.603545  91.185.118.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: File Request    138 361.383217  91.185.118.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: File Status Request    139 362.423795  91.185.118.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request    140 363.363382  91.185.118.XXX        COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts    141 363.364227  91.185.118.XXX        COX.COX.COX.COX       TCP      4439 > 57909 [RST] Seq=211 Len=0    142 363.364393  91.185.118.XXX        COX.COX.COX.COX       TCP      4439 > 57909 [RST] Seq=12714 Len=0     143 378.325755  60.240.62.XXX         COX.COX.COX.COX       TCP      35525 > 57909 [SYN] Seq=0 Len=0 MSS=1402    144 378.559083  60.240.62.XXX         COX.COX.COX.COX       TCP      35525 > 57909 [ACK] Seq=1 Ack=0 Win=65535 Len=0    145 378.566074  60.240.62.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello    146 379.874602  60.240.62.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: File Request    147 380.172513  60.240.62.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: File Status Request    148 380.475457  60.240.62.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request    149 380.765389  60.240.62.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts    150 380.765850  60.240.62.XXX         COX.COX.COX.COX       TCP      35525 > 57909 [RST] Seq=226 Len=0    151 380.765853  60.240.62.XXX         COX.COX.COX.COX       TCP      35525 > 57909 [RST] Seq=12729 Len=0     152 402.541072  82.3.19.XXX           COX.COX.COX.COX       TCP      2746 > 57909 [SYN] Seq=0 Len=0 MSS=1460    153 402.730368  82.3.19.XXX           COX.COX.COX.COX       TCP      2746 > 57909 [ACK] Seq=1 Ack=0 Win=65535 Len=0    154 402.826481  82.3.19.XXX           COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello    155 403.104864  82.3.19.XXX           COX.COX.COX.COX       eDonkey  eMule Extensions TCP: Unknown    156 403.478956  82.3.19.XXX           COX.COX.COX.COX       eDonkey  eDonkey TCP: File Status Request    157 403.776899  82.3.19.XXX           COX.COX.COX.COX       TCP      2746 > 57909 [ACK] Seq=172 Ack=173 Win=65362 Len=0    158 403.964687  82.3.19.XXX           COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request    159 404.155558  82.3.19.XXX           COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts    160 404.156052  82.3.19.XXX           COX.COX.COX.COX       TCP      2746 > 57909 [RST] Seq=240 Len=0    161 404.156054  82.3.19.XXX           COX.COX.COX.COX       TCP      2746 > 57909 [RST] Seq=12743 Len=0     162 407.431919  87.69.87.XXX          COX.COX.COX.COX       TCP      4859 > 57909 [SYN] Seq=0 Len=0 MSS=1360    163 410.426408  87.69.87.XXX          COX.COX.COX.COX       TCP      4859 > 57909 [SYN] Seq=0 Len=0 MSS=1360    164 414.037670  87.69.87.XXX          COX.COX.COX.COX       TCP      4859 > 57909 [ACK] Seq=1 Ack=0 Win=17680 Len=0    165 414.073742  87.69.87.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello    166 418.327109  87.69.87.XXX          COX.COX.COX.COX       TCP      4859 > 57909 [ACK] Seq=110 Ack=109 Win=17571 Len=0    167 418.347794  87.69.87.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: File Request    168 419.350633  87.69.87.XXX          COX.COX.COX.COX       TCP      [TCP Dup ACK 167#1] 4859 > 57909 [ACK] Seq=139 Ack=109 Win=17571 Len=0    169 419.610029  87.69.87.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: File Status Request    170 421.543913  87.69.87.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request    171 424.469308  87.69.87.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts    172 424.469770  87.69.87.XXX          COX.COX.COX.COX       TCP      4859 > 57909 [RST] Seq=229 Len=0    173 424.469943  87.69.87.XXX          COX.COX.COX.COX       TCP      4859 > 57909 [RST] Seq=12732 Len=0     174 434.740736  80.39.85.XXX          COX.COX.COX.COX       TCP      4263 > 57909 [SYN] Seq=0 Len=0 MSS=1420    175 435.180400  80.39.85.XXX          COX.COX.COX.COX       TCP      4263 > 57909 [ACK] Seq=1 Ack=0 Win=65535 Len=0    176 435.186391  80.39.85.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello    178 436.648669  80.39.85.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: File Request    179 437.044771  80.39.85.XXX          COX.COX.COX.COX       eDonkey  eMule Extensions TCP: Sources Request    181 437.412429  80.39.85.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request    182 437.731812  80.39.85.XXX          COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts    183 437.732273  80.39.85.XXX          COX.COX.COX.COX       TCP      4263 > 57909 [RST] Seq=308 Len=0    184 437.732275  80.39.85.XXX          COX.COX.COX.COX       TCP      4263 > 57909 [RST] Seq=12811 Len=0     177 436.639633  151.60.56.XXX         COX.COX.COX.COX       TCP      2594 > 57909 [SYN] Seq=0 Len=0 MSS=1360    180 437.285100  151.60.56.XXX         COX.COX.COX.COX       TCP      2594 > 57909 [ACK] Seq=1 Ack=0 Win=65535 Len=0    185 440.454327  151.60.56.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Hello    186 441.232989  151.60.56.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: File Request    187 441.705203  151.60.56.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: File Status Request    188 442.080811  151.60.56.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Slot Request    189 442.654643  151.60.56.XXX         COX.COX.COX.COX       eDonkey  eDonkey TCP: Request Parts    190 442.655162  151.60.56.XXX         COX.COX.COX.COX       TCP      2594 > 57909 [RST] Seq=228 Len=0    191 442.655336  151.60.56.XXX         COX.COX.COX.COX       TCP      2594 > 57909 [RST] Seq=12731 Len=0

All of the above requests were interrupted by an injected, forged TCP packet with the Abort/Reset [RST] flag set. If the other client actually intended to break off communication, it would have sent a FIN packet as shown in the following...

This is conclusive proof that Cox is interfering with eDonkey uploads by abusing the RST (abort/reset) flag.

--Robb Topolski

--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.]]> http://www.dslreports.com/forum/remark,19449983 Thu, 15 Nov 2007 14:50:59 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19446589 nchw68 : I don't use Bittorrent, but here's a few threads that show my experience with Cox and P2P.

»Cox vs. SBC

»[RI] Bittorrent just stopped uploading....]]> http://www.dslreports.com/forum/remark,19446589 Wed, 14 Nov 2007 23:39:22 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19446453 Tsume : Okay Mr Robb, I sent you a PM of my wireshark monitoring the TCP port Shareaza was using while open for 7 minutes roughly, and I am posting a quick screenie here (I think I've blanked out the appropriate things on this image).

Edit: A small note. The progress bars on those "completed" uploads are all empty, at 0%. That's just how Shareaza shows an ended upload after it's reached the stage of connection established. As far as it knows, the person started downloading it and said wait, screw that, and canceled it. In reality, nothing was transferred and the other person had nothing to do with it. It was COX.

Link to a post I made in 2005 about this on gnutellaforums:
»www.gnutellaforums.com/general-g···ing.html]]> http://www.dslreports.com/forum/remark,19446453 Wed, 14 Nov 2007 23:14:15 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19445987 Tsume :

said by funchords

:

Hey Tsume -- long time!!

said by Tsume

:

I'm at work so I cannot run the test, however I have not experienced any meddling of my Bittorrent packets here in San Diego. I'd have noticed if my speeds dipped drastically :)

You won't notice a speed dip. What you will notice is that, while seeding, several clients will attempt to connect and will only remain connected for 1-3 seconds (disconnected at the handshake) or for 30-60 seconds (disconnected at the BT_REQUEST packet).

Normally, these disconnections shouldn't happen (unless you or the peer is using BitComet which does disconnect on its own).

Using uTorrent, Azureus, or the official BitTorrent client, if you're seeding a large popular file for an hour, you normally will see many peers that are leeching for over 30 minutes in your peer list. However, if Sandvine is interfering, peers rarely can stay connected that long.

If you have logging enabled, you will see error messages relating to Aborted or Reset connections, or Winsock error 10053.

said by Tsume

:

For a long while though they have been blocking Gnutella1/2 and ED2K uploads. The connection is almost instantly reset, and little if any data is uploaded (16kB or less). This wasn't always the case but has been the case for at least a year now. A notable exception is uploads DO go through if the receiver is on the COX network.

*grudgingly reinstalls Shareaza*

I shall! For great justice.]]> http://www.dslreports.com/forum/remark,19445987 Wed, 14 Nov 2007 22:04:05 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19444896 dvd536 :

said by Tsume

said by funchords

said by jmccorm

:

A new response from Cox, including a very direct and unambiguous denial.

[...]

We do not actively interfere with BitTorrent

Excellent! Thanks for sharing this information!

(All: While this looks rather definitive, I'd still appreciate the information -- user test results -- that I mentioned above.)

I'm at work so I cannot run the test, however I have not experienced any meddling of my Bittorrent packets here in San Diego. I'd have noticed if my speeds dipped drastically :)

For a long while though they have been blocking Gnutella1/2 and ED2K uploads. The connection is almost instantly reset, and little if any data is uploaded (16kB or less). This wasn't always the case but has been the case for at least a year now. A notable exception is uploads DO go through if the receiver is on the COX network.

Of course COX doesn't interfere with BT, its the sandvine device that does it.
--
You can never be too rich, too thin or have too much Bandwidth]]> http://www.dslreports.com/forum/remark,19444896 Wed, 14 Nov 2007 19:18:55 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19444189 funchords : Hey Tsume -- long time!!

said by Tsume

:

I'm at work so I cannot run the test, however I have not experienced any meddling of my Bittorrent packets here in San Diego. I'd have noticed if my speeds dipped drastically :)

said by Tsume

That is the Sandvine behavior! Can you get a wireshark capture of this? Either post it here or send it to robb(at-sign)funchords.com, please. (If I use it, I'll make sure to clean it up to protect any identity concerns you might have.)

Thanks

--Robb
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.]]> http://www.dslreports.com/forum/remark,19444189 Wed, 14 Nov 2007 17:09:07 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19444113 Tsume :

said by funchords

said by jmccorm

:

A new response from Cox, including a very direct and unambiguous denial.

[...]

We do not actively interfere with BitTorrent

Excellent! Thanks for sharing this information!

(All: While this looks rather definitive, I'd still appreciate the information -- user test results -- that I mentioned above.)

said by jmccorm

:

A new response from Cox, including a very direct and unambiguous denial.

[...]

We do not actively interfere with BitTorrent

Excellent! Thanks for sharing this information!

(All: While this looks rather definitive, I'd still appreciate the information -- user test results -- that I mentioned above.)
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.]]> http://www.dslreports.com/forum/remark,19443984 Wed, 14 Nov 2007 16:26:48 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19442445 jmccorm : A new response from Cox, including a very direct and unambiguous denial. I'd note that the malformed paragraphs are indicative of heavy cutting and pasting. Emphasis (below) is mine. So here you have it. Cox denies interfering with BitTorrent. (Unless they want to argue that they're not actively interfering with it, but passively interfering with it?!)

Thank you for your e-mail to Cox Communications. I understand that you

want to know if Cox interfere in any way with BitTorrent
traffic? I apologize for this inconvenience.

As you might know Bit Torrent is a Peer-to-Peer service. BitTorrent
metafiles do not store copyrighted data, hence the technology itself
does not constitute copyright infringement. Nevertheless, majority of
BitTorrent trackers users utilize the technology to download
copyrighted
material such as movies and software without legally purchasing them,
consequently, it led to tremendous legal pressure, usually from the
MPAA
and RIAA, to shut down numerous BitTorrent trackers.

Cox Communications adhere with the Intellectual Property Infringement
policy. You may not use the Service to post, copy, transmit, or
disseminate any content that infringes the patents, copyrights, trade
secrets, trademark, or propriety rights of any party. Cox assumes no
responsibility, and you assume all risks regarding the determination of

whether material is in the public domain, or may otherwise be used by
you for such purposes. We do not actively interfere with BitTorrent
and
you are solely responsible for using the service.

Cox also blocks some ports for security reasons. If BitTorrent uses any

of these port, it could be blocked. Please visit the link below where
you can find additional information of the ports Cox block.]]> http://www.dslreports.com/forum/remark,19442445 Wed, 14 Nov 2007 12:08:32 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19439250 spanglo :

said by MarkyD

:

I am starting to think that Cox is using Sandvine in a testing phase in certain markets, OKC being one of them. I personally know of four people that are noticing BitTorrent slowdowns (significant) on Cox in OKC. When I was running Cox and AT&T side by side for a few days, I started one torrent on my AT&T connection and was able to max out my connection with it. The download on Cox was stuck at 80KB/sec.
I have no proof that Cox is doing anything...just observations.

Sounds like a hell of a observation to me.]]> http://www.dslreports.com/forum/remark,19439250 Tue, 13 Nov 2007 21:09:15 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19438612 funchords :

said by AZwldcats

:

Umm....Links?

That's Odd.

Perhaps my message wasn't long enough to generate a signature. At any rate:

Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.

Thanks for letting me know! :-)

--Robb

Ironically, a signature will probably appear below, too!
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.]]> http://www.dslreports.com/forum/remark,19438612 Tue, 13 Nov 2007 19:27:13 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19437843 AZwldcats :
said by funchords :

Some of the Cox reports seem to match my experience with Comcast.

Guys, use the links at the bottom of my post here, and post your results, please.

A wireshark capture of this interference would also be excellent evidence.

-- Robb Topolski

Umm....Links?]]> http://www.dslreports.com/forum/remark,19437843 Tue, 13 Nov 2007 17:19:47 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19437758 funchords : Some of the Cox reports seem to match my experience with Comcast.

Guys, use the links at the bottom of my post here, and post your results, please.

A wireshark capture of this interference would also be excellent evidence.

-- Robb Topolski]]> http://www.dslreports.com/forum/remark,19437758 Tue, 13 Nov 2007 17:03:17 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19434072 Movieman420 : Here's the script I mentioned.

@ECHO OFF
REM
REM Title: NetStat Check Reset V3
REM
REM Description: Extract summary data from Netstat and display percentage of current, average and a histogram of connection resets.
REM
REM CURRENT percentages are the difference between the previous (20 seconds ago) and current Netstat results.
REM AVERAGE percentages are the running total of the current percentages.
REM HISTOGRAM is a ranking of the number of current percentages that occurred. This shows the distribution of resets from 1-99 percent.
REM
REM So while the Average percentage may be 35%, the Histogram may show the majority of Current percentages are in the 20% range
REM with some spikes in the 40% or 50% range. This would indicate normal reset activity to be in the 20% range and the focus would be
REM in resolving the spikes.
REM

SETLOCAL
TITLE NetStat Check Reset V3
CLS
ECHO NetStat Check Reset Batch V3 [Ctrl-c quit]

REM Initialize variables
:init

REM Histogram values
SET HST00=0
SET HST10=0
SET HST20=0
SET HST30=0
SET HST40=0
SET HST50=0
SET HST60=0
SET HST70=0
SET HST80=0
SET HST90=0

REM Histogram print strings
SET PST00=___
SET PST10=___
SET PST20=___
SET PST30=___
SET PST40=___
SET PST50=___
SET PST60=___
SET PST70=___
SET PST80=___
SET PST90=___

REM Loop counter for header print
SET /A TESTCYCLE=-1

REM run Netstat summary page, find line and save 2nd field value
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Active Opens"`) DO SET /A PRVACTI=%%i
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Passive Opens"`) DO SET /A PRVPASS=%%i
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Failed Connection Attempts"`) DO SET /A PRVFAIL=%%i
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Reset Connections"`) DO SET /A PRVRESE=%%i

REM Begin loop section
:begin

REM Increment test cycles
SET /A TESTCYCLE=%TESTCYCLE%+1
IF %TESTCYCLE% GEQ 10 SET /A TESTCYCLE=0

REM Ping to nul used as timer
REM Each ping approximately 1 second delay
REM Value of 20 used as minimum wait time for connection activity.
REM
ping -n 20 localhost >nul

REM run Netstat summary page, find line and save 2nd field value
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Active Opens"`) DO SET /A NXTACTI=%%i
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Passive Opens"`) DO SET /A NXTPASS=%%i
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Failed Connection Attempts"`) DO SET /A NXTFAIL=%%i
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Reset Connections"`) DO SET /A NXTRESE=%%i

REM Subtract Previous from Next to get Current
SET /A CURACTI=%NXTACTI%-%PRVACTI%
SET /A CURPASS=%NXTPASS%-%PRVPASS%
SET /A CURFAIL=%NXTFAIL%-%PRVFAIL%
SET /A CURRESE=%NXTRESE%-%PRVRESE%

REM Accumulate the totals for averaging
SET /A CUMACTI=%CUMACTI%+%CURACTI%
SET /A CUMPASS=%CUMPASS%+%CURPASS%
SET /A CUMFAIL=%CUMFAIL%+%CURFAIL%
SET /A CUMRESE=%CUMRESE%+%CURRESE%

REM Add Active and Passive connections then subtract Failed connections
REM Calculate Percentage of Resets
SET /A CURESTA=(%CURACTI%+%CURPASS%)-%CURFAIL%

REM Bypass divide by zero errors
SET /A CURPRCT=0
IF %CURESTA% NEQ 0 SET /A CURPRCT=(%CURRESE%*100)/%CURESTA%

REM Accumulate current results for session average
SET /A CUMESTA=(%CUMACTI%+%CUMPASS%)-%CUMFAIL%

REM Bypass divide by zero errors
SET /A CUMPRCT=0
IF %CUMESTA% NEQ 0 SET /A CUMPRCT=(%CUMRESE%*100)/%CUMESTA%

REM Load histogram with current percentages in the range of 1-99%
IF %CURPRCT% LEQ 0 GOTO display

:break00
IF %CURPRCT% GEQ 10 GOTO break10
SET /A HST00=%HST00%+1
SET PST00=%HST00%
IF %HST00% LSS 10 SET PST00=_%PST00%
IF %HST00% LSS 100 SET PST00=_%PST00%
GOTO display

:break10
IF %CURPRCT% GEQ 20 GOTO break20
SET /A HST10=%HST10%+1
SET PST10=%HST10%
IF %HST10% LSS 10 SET PST10=_%PST10%
IF %HST10% LSS 100 SET PST10=_%PST10%
GOTO display

:break20
IF %CURPRCT% GEQ 30 GOTO break30
SET /A HST20=%HST20%+1
SET PST20=%HST20%
IF %HST20% LSS 10 SET PST20=_%PST20%
IF %HST20% LSS 100 SET PST20=_%PST20%
GOTO display

:break30
IF %CURPRCT% GEQ 40 GOTO break40
SET /A HST30=%HST30%+1
SET PST30=%HST30%
IF %HST30% LSS 10 SET PST30=_%PST30%
IF %HST30% LSS 100 SET PST30=_%PST30%
GOTO display

:break40
IF %CURPRCT% GEQ 50 GOTO break50
SET /A HST40=%HST40%+1
SET PST40=%HST40%
IF %HST40% LSS 10 SET PST40=_%PST40%
IF %HST40% LSS 100 SET PST40=_%PST40%
GOTO display

:break50
IF %CURPRCT% GEQ 60 GOTO break60
SET /A HST50=%HST50%+1
SET PST50=%HST50%
IF %HST50% LSS 10 SET PST50=_%PST50%
IF %HST50% LSS 100 SET PST50=_%PST50%
GOTO display

:break60
IF %CURPRCT% GEQ 70 GOTO break70
SET /A HST60=%HST60%+1
SET PST60=%HST60%
IF %HST60% LSS 10 SET PST60=_%PST60%
IF %HST60% LSS 100 SET PST60=_%PST60%
GOTO display

:break70
IF %CURPRCT% GEQ 80 GOTO break80
SET /A HST70=%HST70%+1
SET PST70=%HST70%
IF %HST70% LSS 10 SET PST70=_%PST70%
IF %HST70% LSS 100 SET PST70=_%PST70%
GOTO display

:break80
IF %CURPRCT% GEQ 90 GOTO break90
SET /A HST80=%HST80%+1
SET PST80=%HST80%
IF %HST80% LSS 10 SET PST80=_%PST80%
IF %HST80% LSS 100 SET PST80=_%PST80%
GOTO display

:break90
IF %CURPRCT% GEQ 100 GOTO break100
SET /A HST90=%HST90%+1
SET PST90=%HST90%
IF %HST90% LSS 10 SET PST90=_%PST90%
IF %HST90% LSS 100 SET PST90=_%PST90%
GOTO display

:break100

REM Final formatting and print
:display

REM Assign values to print strings
SET PCUMESTA=%CUMESTA%
SET PCUMRESE=%CUMRESE%
SET PCUMPRCT=%CUMPRCT%
SET PCURESTA=%CURESTA%
SET PCURRESE=%CURRESE%
SET PCURPRCT=%CURPRCT%

REM Skip leading zero for negative numbers
IF %CUMESTA% LSS 0 GOTO dbreak1
IF %CUMESTA% LSS 10 SET PCUMESTA=0%CUMESTA%
:dbreak1

IF %CUMRESE% LSS 0 GOTO dbreak2
IF %CUMRESE% LSS 10 SET PCUMRESE=0%CUMRESE%
:dbreak2

IF %CURESTA% LSS 0 GOTO dbreak3
IF %CURESTA% LSS 10 SET PCURESTA=0%CURESTA%
:dbreak3

IF %CURRESE% LSS 0 GOTO dbreak4
IF %CURRESE% LSS 10 SET PCURRESE=0%CURRESE%
:dbreak4

REM Print line break and header every 10 cycles
IF %TESTCYCLE% EQU 0 ECHO .
IF %TESTCYCLE% EQU 0 ECHO %TIME% - CURRENT AVERAGE I 00%% I 10%% I 20%% I 30%% I 40%% I 50%% I 60%% I 70%% I 80%% I 90%% I

REM Print Current percentage, Average Percentage and Histogram
ECHO %TIME% - %PCURPRCT%%% (%PCURRESE%/%PCURESTA%) %PCUMPRCT%%% (%PCUMRESE%/%PCUMESTA%) I %PST00% I %PST10% I %PST20% I %PST30% I %PST40% I %PST50% I %PST60% I %PST70% I %PST80% I %PST90% I

REM Save values into Previous
SET /A PRVACTI=%NXTACTI%
SET /A PRVPASS=%NXTPASS%
SET /A PRVFAIL=%NXTFAIL%
SET /A PRVRESE=%NXTRESE%

REM Loop again
GOTO begin

Copy and paste this in notepad and save it as CheckRST.bat
Then run it whilst seeding to see if your getting hit by sandvine. More deets here:

»How to test how many connections are being reset by RST pack]]> http://www.dslreports.com/forum/remark,19434072 Tue, 13 Nov 2007 01:52:09 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19433146 jmccorm : I have my first official denial from Cox:

Question:
I have a very basic question that I was needing an _authoritative_ answer on: "Does Cox interfere, in any way, with BitTorrent traffic?"

Answer:
Thank you for your e-mail. I understand that you would like to know if Cox interfere with BitTorrent traffic.

On this matter, I can tell you that Cox does not block the ability to upload or download files.

My comments:
While it appears (on the surface) that they are saying, "no", the answer is actually non-responsive. I asked if they interfered, in any way, with BitTorrent traffic. Their reply was that they do not block the ability to upload or download files.

And it appears that they're answering from a 10,000ft level. They appear to be blocking individual upload streams for periods of time. But the result at the 10,000ft level (not individual connections, but over the course of hours) isn't to block the ability to upload or download files, but to degrade the ability to upload files.]]> http://www.dslreports.com/forum/remark,19433146 Mon, 12 Nov 2007 22:52:51 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19432856 Movieman420 : Nope...can't be broken, only avoided by using a VPN or SSH connection. Goto torrentfreak.com they have a how-to just for Comcast victims that will work for you as well.

In the early pages of the Comcasat thread I linked above, there it a script you can run (written by a CC user) that tells you in real time what % of your connections are getting killed by RSTs. Best to test after you've d/led and are trying to seed..that's where you get nailed. Up to an 80% rst rate while seeding..about 20% while downloading. Normal (legit) RST rates rarely top 3-5% avg.]]> http://www.dslreports.com/forum/remark,19432856 Mon, 12 Nov 2007 22:12:29 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19431202 dvd536 : Does the firewall rule break the RST crap or is it too late once it hits the firewall?
I haven't used BT in a while so i don't know if its happening here.
--
You can never be too rich, too thin or have too much Bandwidth]]> http://www.dslreports.com/forum/remark,19431202 Mon, 12 Nov 2007 18:07:57 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19425114 Movieman420 : Sorry to say but from what I've been reading here and on the net, looks like Cox is using Sandvine as well.

»Comcast is using Sandvine to manage P2P Connections

Comcast is in real hot water over this (last few pages of the thread contains links)as they're still denying it. Congress is even getting involved and the FCC has received legal complaints as well. I'm betting that Cox will tell their customers about traffic shaping and offer customer support regarding it...unlike CC.

Even the EFF is contemplating a class action law suit.

Them managing their network is fine but doing via forgery (and denying it!) is the wrong way to do it. Not to mention it also increases their profits at the same time.]]> http://www.dslreports.com/forum/remark,19425114 Sun, 11 Nov 2007 19:11:42 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19424827 Pyrion : I'm not asking a question, I'm pointing out a flaw in reasoning.]]> http://www.dslreports.com/forum/remark,19424827 Sun, 11 Nov 2007 18:01:40 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19424573 jmccorm :
said by Pyrion :

Are ISPs going to bed with the RIAA/MPAA? talk about censorship and btw, their ads say "download movies/music at blazing speeds"

Note the lack of the keyword "illegally" in that statement.

I think that you both have a good question for Cox, just you are asking it in different ways:

Assuming Cox is interfering with BitTorrent...
1] Are they doing this to partially curtail piracy on their network?
2] Or are they doing it to preserve more free bandwidth on their network?]]> http://www.dslreports.com/forum/remark,19424573 Sun, 11 Nov 2007 17:04:15 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19422219 Pyrion :
said by robertfl :

Are ISPs going to bed with the RIAA/MPAA? talk about censorship and btw, their ads say "download movies/music at blazing speeds"

-Rob

Note the lack of the keyword "illegally" in that statement.
--
"There is much pleasure to be gained from useless knowledge." - Bertrand Russell]]> http://www.dslreports.com/forum/remark,19422219 Sun, 11 Nov 2007 06:04:29 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19421310 jmccorm :
said by bom619 :

Having unpredictable results in San Diego as well. New behavior... very strange.
This guy was also complaining about BitTorrent uploading problems, in San Diego, but he got lost in a bunch of noise of people, who aren't Cox employees, telling him there isn't a problem:
»[CA] Packet Shaping, San Diego

I download IPFW and added the following firewall rule...
deny tcp from any to me 6881 tcp flags rst
...and ran another test. In a period of 5 minutes, the firewall rule detected OVER 2000 RST packets on the BitTorrent port.

I didn't run a packet sniffer on both sides of a BitTorrent connection to prove that fake RST packets are being generated, but I think I've proved to my own satisfaction that Cox is engaging in Comcast-like behavior. Even still, I want an answer from a Cox employee who can speak authoritatively on this.

The question, again: "Does Cox interfere, in any way, with BitTorrent traffic?"]]> http://www.dslreports.com/forum/remark,19421310 Sat, 10 Nov 2007 23:01:22 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19421163 robertfl : Are ISPs going to bed with the RIAA/MPAA? talk about censorship and btw, their ads say "download movies/music at blazing speeds"

-Rob]]> http://www.dslreports.com/forum/remark,19421163 Sat, 10 Nov 2007 22:30:05 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19421152 bom619 : Having unpredictable results in San Diego as well. New behavior... very strange. ]]> http://www.dslreports.com/forum/remark,19421152 Sat, 10 Nov 2007 22:27:08 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19420947 MarkyD : I find it interesting that we're both in Oklahoma and noticing similar behavior.]]> http://www.dslreports.com/forum/remark,19420947 Sat, 10 Nov 2007 21:40:35 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19420524 jmccorm :
said by MarkyD :

I am starting to think that Cox is using Sandvine in a testing phase in certain markets, OKC being one of them.
Actually, I brought up the topic because I suspect that Cox is interfering with my connection.

I recently had the rare need to provide a file to my team via Bittorrent. This time around, I noticed all sorts of problems (individual upstream connections going to 0kB/s after 10 seconds). And all sorts of randomness, rarely able to even come close (not to mention sustain) my self-imposed cap of 30kB/s.

I would have suspected a problem with up my upstream path, but my FTPs are 100% rock solid. Back to Bittorrent... I tried downloading off of a public torrent server, and was able to download just great, but my upload throughput was weak and random.

Example FTP stats...
> 9558016 bytes sent in 140.65Seconds 67.96Kbytes/sec.

Has anyone from Cox answered the original question, or has a response been avoided so far? "Cox doesn't mess with Bittorrent traffic, does it?"]]> http://www.dslreports.com/forum/remark,19420524 Sat, 10 Nov 2007 20:18:46 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19419684 robertfl : Just for this, we should be able to get our full download speed on newsgroups, not 512K

-Rob]]> http://www.dslreports.com/forum/remark,19419684 Sat, 10 Nov 2007 17:09:17 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19419504 dvd536 :
said by MarkyD :

I am starting to think that Cox is using Sandvine in a testing phase in certain markets, OKC being one of them.
Easy to verify if you use utorrent, view the clients and if you see them connect and immediately disconnect, its sandvine or similar quality of service degradation service.
--
You can never be too rich, too thin or have too much Bandwidth]]> http://www.dslreports.com/forum/remark,19419504 Sat, 10 Nov 2007 16:28:57 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19419052 MarkyD : I am starting to think that Cox is using Sandvine in a testing phase in certain markets, OKC being one of them. I personally know of four people that are noticing BitTorrent slowdowns (significant) on Cox in OKC. When I was running Cox and AT&T side by side for a few days, I started one torrent on my AT&T connection and was able to max out my connection with it. The download on Cox was stuck at 80KB/sec.
I have no proof that Cox is doing anything...just observations.
--
MCSE, ACSA, and a lot more]]> http://www.dslreports.com/forum/remark,19419052 Sat, 10 Nov 2007 14:55:53 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19416838 Pyrion :
said by AZwldcats :

Caps are loosely enforced,

If they are you will get a warning email to yoour primary cox.net account
A classmate of mine got a call from Cox telling him he had blown through his cap and got another gig for the rest of the month before he'd be kicked off.

I assume that's standard practice for repeat offenders cuz this guy treated high bandwidth use as some sort of badge of honor.
--
"There is much pleasure to be gained from useless knowledge." - Bertrand Russell]]> http://www.dslreports.com/forum/remark,19416838 Sat, 10 Nov 2007 02:23:41 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19414091 dvd536 :
said by AZwldcats :

said by dvd536 :

said by robertfl :

but what about traffic shaping? i don't think cox does that (yet) but we hope that cox won't follow comcast evil ways of telling us what we can and can not do (within reason) on what we are paying for.
Thats when i drop cox like a rock and just use one of the 6 open wireless APs available to me.

Great attitude :uhh:

Nothing like causing problems for your neighbors...

If they're too ignorant/stupid to configure their routers then thats their problem. most of em are Qwest DSL and two are standard cox(preferred).
--
You can never be too rich, too thin or have too much Bandwidth]]> http://www.dslreports.com/forum/remark,19414091 Fri, 09 Nov 2007 17:09:49 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19411838 Phaetos : Hmm ..strange. I got hit with a C&D a few weeks back by Cox, for the one and only thing I ever tried to get off Torrent. Ever since then UTorrent won't connect and neither will the original BT client. won't work at all. but I can use the updated version of limewire that supports torrents now and it works fine.]]> http://www.dslreports.com/forum/remark,19411838 Fri, 09 Nov 2007 10:48:45 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19410882 MarkyD :
said by spanglo :

That does sound odd.
I regularly get over a 1MB/sec on my torrents with Premiere.
Anyone else in your area getting the same results?

My neighbor and friend has experienced the same. Strange thing is, we can max out our connection no problem on websites like Microsoft, Apple...
--
MCSE, ACSA, and a lot more]]> http://www.dslreports.com/forum/remark,19410882 Fri, 09 Nov 2007 06:55:50 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19409518 anon :
said by AZwldcats :

Great attitude :uhh:

Nothing like causing problems for your neighbors...

You never know... His neighbors might be the biggest jerks on the planet. :D]]> http://www.dslreports.com/forum/remark,19409518 Thu, 08 Nov 2007 21:45:21 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19408266 AZwldcats :
said by dvd536 :

said by robertfl :

but what about traffic shaping? i don't think cox does that (yet) but we hope that cox won't follow comcast evil ways of telling us what we can and can not do (within reason) on what we are paying for.
Thats when i drop cox like a rock and just use one of the 6 open wireless APs available to me.

Great attitude :uhh:

Nothing like causing problems for your neighbors...]]> http://www.dslreports.com/forum/remark,19408266 Thu, 08 Nov 2007 18:07:21 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19407258 spanglo :
said by MarkyD :

said by AZwldcats :

said by MarkyD :

all i can say with certainty is this. My torrents download much slower on my Cox 12/1 connection than they did on my AT&T 6/1 FTTP connection. I've tried changing clients, made sure my ports are forwarded properly, changed routers...It's a mystery.

How much slower?

I could max out my 6mbps pipe on ATT. On Cox I can never break 500KB/sec no matter how many torrents I have running, or how good the sources are.

That does sound odd.
I regularly get over a 1MB/sec on my torrents with Premiere.
Anyone else in your area getting the same results? ]]> http://www.dslreports.com/forum/remark,19407258 Thu, 08 Nov 2007 15:17:02 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19407119 dvd536 :
said by KrK :

Wow, these are some really ridiculously low caps... Only 40gigabytes downstream a month?

They'd better not enforce them I think there would be many many users who go over that, and it's only going to increase.

Got to agree with you there. even comcast gives you 90 gigs a month.
--
You can never be too rich, too thin or have too much Bandwidth]]> http://www.dslreports.com/forum/remark,19407119 Thu, 08 Nov 2007 14:53:28 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19407100 dvd536 :
said by robertfl :

but what about traffic shaping? i don't think cox does that (yet) but we hope that cox won't follow comcast evil ways of telling us what we can and can not do (within reason) on what we are paying for.
Thats when i drop cox like a rock and just use one of the 6 open wireless APs available to me.
--
You can never be too rich, too thin or have too much Bandwidth]]> http://www.dslreports.com/forum/remark,19407100 Thu, 08 Nov 2007 14:50:25 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19404224 KrK : Wow, these are some really ridiculously low caps... Only 40gigabytes downstream a month?

They'd better not enforce them I think there would be many many users who go over that, and it's only going to increase.]]> http://www.dslreports.com/forum/remark,19404224 Thu, 08 Nov 2007 01:32:17 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19403514 MarkyD :
said by AZwldcats :

said by MarkyD :

all i can say with certainty is this. My torrents download much slower on my Cox 12/1 connection than they did on my AT&T 6/1 FTTP connection. I've tried changing clients, made sure my ports are forwarded properly, changed routers...It's a mystery.

How much slower?

I could max out my 6mbps pipe on ATT. On Cox I can never break 500KB/sec no matter how many torrents I have running, or how good the sources are.]]> http://www.dslreports.com/forum/remark,19403514 Wed, 07 Nov 2007 22:48:43 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19403506 MarkyD :
said by SkateZilla :

Cox monitors bit torrent, you download stuff your not supposed to and they'll nail you.

ever heard of peerguardian?]]> http://www.dslreports.com/forum/remark,19403506 Wed, 07 Nov 2007 22:48:02 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19403262 robertfl : they have other 3rd parties who monitor the traffic. why you need to protect yourself.

greed is a very powerful tool and why to this day i don't buy any cd's.

-rob]]> http://www.dslreports.com/forum/remark,19403262 Wed, 07 Nov 2007 22:09:38 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19403205 AZwldcats : Cox Won't and doesn't care...

The RIAA does though]]> http://www.dslreports.com/forum/remark,19403205 Wed, 07 Nov 2007 22:01:56 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19402801 needforspeed59 : You have proof or just conjecture?
--
Great success! High five!]]> http://www.dslreports.com/forum/remark,19402801 Wed, 07 Nov 2007 20:59:41 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19402765 SkateZilla : Cox monitors bit torrent, you download stuff your not supposed to and they'll nail you.]]> http://www.dslreports.com/forum/remark,19402765 Wed, 07 Nov 2007 20:54:26 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19402470 AZwldcats :
said by MarkyD :

all i can say with certainty is this. My torrents download much slower on my Cox 12/1 connection than they did on my AT&T 6/1 FTTP connection. I've tried changing clients, made sure my ports are forwarded properly, changed routers...It's a mystery.

How much slower?]]> http://www.dslreports.com/forum/remark,19402470 Wed, 07 Nov 2007 20:14:44 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19402339 MarkyD : all i can say with certainty is this. My torrents download much slower on my Cox 12/1 connection than they did on my AT&T 6/1 FTTP connection. I've tried changing clients, made sure my ports are forwarded properly, changed routers...It's a mystery.
--
MCSE, ACSA, and a lot more]]> http://www.dslreports.com/forum/remark,19402339 Wed, 07 Nov 2007 19:48:13 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19402090 AZwldcats :
said by robertfl :

but what about traffic shaping? i don't think cox does that (yet) but we hope that cox won't follow comcast evil ways of telling us what we can and can not do (within reason) on what we are paying for.

-rob

You already answered the question.... Are you unsure of your answer?

But I haven;t seen any evidence of Traffic shaping... Hasn't happened with me....]]> http://www.dslreports.com/forum/remark,19402090 Wed, 07 Nov 2007 19:03:07 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19401817 robertfl : but what about traffic shaping? i don't think cox does that (yet) but we hope that cox won't follow comcast evil ways of telling us what we can and can not do (within reason) on what we are paying for.

-rob]]> http://www.dslreports.com/forum/remark,19401817 Wed, 07 Nov 2007 18:16:31 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19401800 AZwldcats : Caps are loosely enforced,

If they are you will get a warning email to yoour primary cox.net account....

Continued abuse would prob lead to account termination..

But like I said, Caps are VERY loosely enforced]]> http://www.dslreports.com/forum/remark,19401800 Wed, 07 Nov 2007 18:12:55 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19401308 jmccorm : What exactly happens when one exceeds a limit that Cox lists at the URL below?
»www.cox.com/policy/limitations.asp

re: maximum monthly consumption caps]]> http://www.dslreports.com/forum/remark,19401308 Wed, 07 Nov 2007 16:55:54 EDT Re: [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19400881 robertfl : not yet. but don't give them any ideas.

-rob]]> http://www.dslreports.com/forum/remark,19400881 Wed, 07 Nov 2007 15:50:05 EDT [OK] Cox doesn't mess with Bittorrent traffic, does it? http://www.dslreports.com/forum/remark,19400841 jmccorm : Does Cox interfere in any way with Bittorrent traffic? Be it interfering with seeding, like Comcast is recently accused of, or traffic shaping, or some other degradation of service?]]> http://www.dslreports.com/forum/remark,19400841 Wed, 07 Nov 2007 15:42:11 EDT