Comcast XFINITY → Re: Comcast is using Sandvine to manage P2P Connections

(in my case, after the CHOKE). But I definitely remember seeing something to that effect, too -- encrypted connections lasted longer, but I did not dig deeper to characterize it. I remember wondering at the time if it had anything to do with how encryption was negotiated in the handshake. My goal at the time, however, was just to record under what conditions RST interference happened.

Has anyone tried configuring their firewall to block incoming RST packets? While this may lead to a lot of stale TCP connections hanging around until they time out (typical timeouts are 5-10 minutes), it may alleviate some of the problems Robb has reported. Alternatively, if the bogus RST packets could somehow be characterized (e.g. empty message body), then perhaps the firewall could be configured to block only these types of RST packets.

I guess the next question is whether or not there are any software firewalls with sufficient flexibility to allow this type of filtering?

The two non-Windows firewalls I worked with could filter by TCP, or UDP, by IP address and by port number; but I don't recall that either could check for RST packets.

I haven't played with the Windows firewall. My router firewall can't check that low.

I have not (since I haven't seen this behavior), but any of the UNIX-based firewalls can filter using TCP header, as can OS X (FreeBSD's ipfw), and I'm sure any of the enterprise-grade hardware firewalls. It can probably be done with the Linux-based Linksys routers through the commandline interface. I'd be interested to hear of any others.

If anybody figures out how to try this firewall filtering with a DD-WRT firmware-flashed Linksys, please post instructions here. I'm about to get kicked off several **legal** (live-music-sharing) torrent trackers for my piss-poor ratio.

Yes!
On linux, if you're using a static port for bittorrent, the following command drops incoming reset packets to that port.

iptables -A INPUT -p tcp --dport PORTNUMBERHERE --tcp-flags RST RST -j DROP
 

I also noticed, that bit 6 of the IP TOS field was set on all these reset packets.
As per the ipv4 rfc, bit 6 is "Reserved for future use". tcpdump shows these packets with

tcpdump -n "ip[1] & 0xff == 0x40"
 

Since that field is not in use, tcpdump should never show any packets with that filter. But it does on comcast! Could someone else on comcast plese verify that they can see these too?

iptables 1.3.5
tcpdump version 3.9.4
libpcap version 0.9.4
linux 2.6.20.1

Yes, I tried this with linux iptables, and got really excited when it seemed to thwart the problem. But then I realized that the connections were dead, but they simply weren't being removed from the active list.

I believe this means that the RST is sent both ways. The response to an RST is not a FIN so the TCP/IP stack doesn't know the connection has been dropped.

Good thinking, though.I hadn't noticed. They could have been set, or not. Are you directly connected? -- or could your router be adding that bit for use on the LAN?

I'm not directly connected, there's a router on the way, but this bit is set only on the reset packets I'm receiving on the bittorrent connections and nowhere else.

Correct . See the below stateful diagram (PDF):

»www.cse.iitb.ac.in/perfn ··· diag.pdf