wierdo
join:2001-02-16
Tulsa, OK
 ·Future Nine Corpor..
·Teliax VOIP
 ·Cox HSI
edit:
November 15th, @05:26PM
| reply to funchords
Re: Here's Proof: Cox Interferes with P2P Uploads
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
Robb
Premium,MVM
join:2001-03-11
Hillsboro, OR
 ·Verizon Online DSL
·Skype
·Comcast
| 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. |
|
wierdo
join:2001-02-16
Tulsa, OK
·Future Nine Corpor..
·Teliax VOIP
·Cox HSI
| 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
·Cox HSI
| 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
Robb
Premium,MVM
join:2001-03-11
Hillsboro, OR
·Verizon Online DSL
·Skype
·Comcast
| 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. |
|
