how-to block ads
|
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
 ·Verizon Online DSL
 ·Skype
| reply to wierdo
Re: Here's Proof: Cox Interferes with P2P Uploads
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. | |
robertfl
Premium
join:2005-10-10
Mary Esther, FL
·Cox VOIP
| reply to wierdo
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 | |
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. | |
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' | |
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. | |
robertfl
Premium
join:2005-10-10
Mary Esther, FL | reply to wierdo
Welcome to 1984. I think other ISP's will follow suit as well.
-Rob | |
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. | |
kingofdsl
join:2002-12-11
Afton, OK | reply to funchords
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? | |
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype
1 edit | reply to Tsume
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. | |
|
