[tweakmonkey]

In a previous post, we talked about Comcast's efforts to block seeders to prevent torrents from functioning as intended. Here's the potential fix:

Recently, Comcast has stopped the seeding of torrents.

Basically, what they're doing is telling your computer it needs to close it's TCP connection at a certain port (in this case, your torrent clients' port) via the RST TCP reset command.

Since they're using such basic methods to stop seeding, there's a simple way to stop them from stopping you. Although I have no fix for the Windows operating system, in Linux, it's a simple fix. Every modern Linux distribution has iptables, so all you have to do is set it up to block this RST command. This should also work in BSD systems, Mac OS X, or any system with iptables.

All you have to do is run the following command, with superuser privileges (sudo, fakeroot, a super user terminal, etc). The one thing you need to do, is change the word $port to whatever port your torrent client uses.
Run in your shell/terminal: iptables -A INPUT -p tcp --dport $port --tcp-flags RST RST -j DROP

Also, should you ever need to remove this, all we need to do is make that A (for Append) a D (for Delete). The resulting command would be:
Run in your shell/terminal: iptables -D INPUT -p tcp --dport $port --tcp-flags RST RST -j DROP

In addition, I believe that if you have a router running some variant of Linux (DD-WRT, Open-WRT, etc), this trick should work on that, since all we're doing is dropping RST commands.. All you should need to do is ssh or telnet into your router and run the command with the appropriate port, however, I haven't tested this, so do this with caution.

If you have Windows, well, you're SOL for now. Although, I expect a solution will reveal itself in the coming months.

Give it a whirl and let us know how it works if you're a Comcast user having issues with torrents.
Original Source, now dead

Im running ubuntu 7.04 and get this when i ran that.
sudo iptables -A INPUT -p tcp --dport $port --tcp-flags RST RST -j DROP
Password:
iptables v1.3.6: invalid port/service `--tcp-flags' specified
Try `iptables -h' or 'iptables --help' for more information.

.... what now

[funchords]

Tests and Results-RSTs are set in both directions

Tests and Results-RSTs are set in both directions - dslreports.com

Comcast users should not modify their firewalls to drop RST packets as it is not an effective defense against the injected RST packets.

Can somebody help me get this working with OS X? Thanks.

very nice! worked for me...running fc6.

thanks!

Originally Posted by Unregistered

Can somebody help me get this working with OS X? Thanks.

I need help for OS X me too...
Could someone give us a reply??
Thanks in advance

Running Ubuntu---works great. Thank you very much!

[falk0069]

Im a Comcast customer and am starting to experience my seed connections getting dropped rapidly. I'm also currently running utorrent on a windows system; however since I'm using a Linksys WRT54G router which I loaded DD-WRT on, I am able to play with the firewall/router configurations directly on it using ssh

I've noticed that the "iptables -A INPUT ..." doesn't seem to do anything, however the "iptable -I FORWARD 7 ..." does. I believe because the linksys isn't receiving the packet but rather forwarding them. I also had to use the -I option so I can have it be higher in the chain. I didn't want to choose 1 because then to would have to check that rule every time a packet comes in; but it had to be before my actual torrent forwarded port rule (8th).

The full command I used was this:
iptables -I FORWARD 7 -p tcp --dport 43333 --tcp-flags RST RST -j DROP

note: I use port 43333 as my torrent port

I was able to verify that packet were being dropped by this command:
iptables -L -v

output:
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- br0 br0 anywhere anywhere
0 0 logdrop all -- any any anywhere anywhere state INVALID
0 0 TCPMSS tcp -- any any anywhere anywhere tcp flags:SYN,RST/SYN tcpmss match 1461:65535 TCPMSS set 1460
68529 22M lan2wan all -- br0 any anywhere anywhere
120K 59M ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
0 0 ACCEPT udp -- vlan1 any anywhere BASE-ADDRESS.MCAST.NET/4 udp
12 504 DROP tcp -- any any anywhere anywhere tcp dpt:43333 flags:RST/RST

This tells me that I've already dropped 12 RST packets

I then added that command to the Startup script which can be editted from within the DD-WRT web console (Administration -> Commands). I had to actually add a delay for it to take affect. I know it isn't elegant but this seemed to do the trick for me:
echo 'sleep 30; iptables -I FORWARD 7 -p tcp --dport 43333 --tcp-flags RST RST -j DROP' > /tmp/root/iptable.sh
chmod 755 /tmp/root/iptable.sh
/tmp/root/iptable.sh &

Also have my TCP/UDP Timeout setting set to 90 seconds just to make sure old connections don't stick around (Administration -> Management in the web console)

Thanks for posting this solution!

[mistawiskas]

Arrrrrrgh!
That'sa all ima gonna say Luigi.

[falk0069]

Well, I must say that my upload ratios have definitely improved after dropping the RST packets, but they are not back to normally. It is definitely true that the RST packets are sent in both directions, however, I'm finding that there are some connections now that don't drop that are outside the comcast network.

Many of the non-dropping connections are coming from Europe and Asia which I wonder if they have similar restrictions. I know the Great Firewall of China have been doing this for years, so that might explain my Asian connections. Hopefully if more people start doing this the better off the torrent community will be.

Also, I'm currently seeding 11 files and my current connection count was around 900 connections. I just dropped my TCP/UDP connection timeout to 45 seconds from 90 seconds and my currently connections dropped to 750, so not a huge difference.

[Justin3]

Its comcastic!

[tweakmonkey]

Bump in case anyone missed it the first time around.

[dertyz]

I want everyone who has read ANYWHERE that using Linux or Mac IP Tables to drop the forged packets with with the rst flag set won't help solve your peering problems to IGNORE what all the negative nellies are telling you!! I was a windows user on Comcast's network and until yesterday, my seeding capacity was ZERO...period...no seeding unless it was during the initial download. Yesterday I installed Ubuntu, dropped those bad, bad rst packets with the proper command and VOILA! I was seeding like crazy. So, if you wanna stick it to Comcast and everyone else using Sandvine - SWITCH TO LINUX OR MAC AND USE YOUR IP TABLES TO DROP THE FORGED RST PACKETS!!! It will fix your problem because now EVERYONE ELSE IS DROPPING THEIR PACKETS TOO!! So the packets get dropped from both sides and no rst is performed. JUST DO IT!! You'll be glad you did. I'll be happy to send you screen shots of two machines, side by side, one on windows and one on Linux...with the windows machine seeding to no one and the linux machine seeding like crazy. It really works! BELIEVE IT!