how-to block ads
|
Tsume
join:2004-02-23
Johnson City, TN
 ·Embarq
 ·ViaTalk
 ·Comcast
| reply to funchords
Re: [OK] Cox doesn't mess with Bittorrent traffic, does it?
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. 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 *grudgingly reinstalls Shareaza*
I shall! For great justice. | |
Tsume
join:2004-02-23
Johnson City, TN
·Embarq
·ViaTalk
·Comcast
1 edit | 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 | |
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype
1 edit | Here's Proof: Cox Interferes with P2P Uploads
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.
Here are the other attempts from peers attempting to download from a peer using Cox:
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. | |
kingofdsl
join:2002-12-11
Afton, OK | 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? | |
wierdo
join:2001-02-16
Tulsa, OK
·Future Nine Corpor..
·Teliax VOIP
1 edit | reply to funchords
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. | |
robertfl
Premium
join:2005-10-10
Mary Esther, FL | Welcome to 1984. I think other ISP's will follow suit as well.
-Rob | |
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype
| reply to wierdo
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. | |
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype
| reply to kingofdsl
said by kingofdsl :How is it abuse when Cox owns the network? Answered here:
»My use of the word 'Abuse' | |
wierdo
join:2001-02-16
Tulsa, OK
·Future Nine Corpor..
·Teliax VOIP
| reply to funchords
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. | |
robertfl
Premium
join:2005-10-10
Mary Esther, FL
·Cox VOIP
| 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 | |
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype
| reply to wierdo
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. | |
|
