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: 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 [digg]http://www.digg.com/linux_unix/Linux_Fix_for_Comcast_Torrent_Blocking_2[/digg]
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
It won't work... 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.
Working with LinkSys DD-WRT 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!
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.
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!
It works! Confirming that this works with Ubuntu 8.10 Intrepid. I am so happy to be able to seed on comcast! I felt like such a jerk before that I was not able to share with others but thanks to this trick now I can! And Comcast should be glad I found this trick because I was about to drop them as my ISP because of the blocked seeding. Just make sure your ports are forwarded correctly first. (see website below if you dont know what I am talking about) PortForward.com - Free Help Setting up Your Router or Firewall
What a lame attempt to block torrents. If thats what they want to do there are many more effective ways out there. My guess is they don't want to tear packets apart up to layer 7 because it would cause way to much additional cpu strain and latency on thier routers. I can see how this could interfere with many kinds of traffic, depending on the interval they set for sending RST flags. Anyone know if they are still doing this?
