Get the NEW Torrent Search NOW!!



GUIDE: Using Linux to Beat Comcast's BitTorrent Throttling

posted by soulxtc in guides // 138 days 23 hours 8 minutes ago

For those savvy enough to have switched over to Linux, this step-by-step guide will prove once again that Linux really does offer users almost complete control over their OS.


It's no secret that Comcast and other ISPs are actively throttling BitTorrent, but how to circumvent the practice is always subject to debate.


Some find protocol header encryption fairly successful, others use TOR or an SSH or a VPN Tunnel to disguise their traffic. Using TOR for file-sharing is discouraged by many who think it should only be used for academic or freedom of speech concerns and not to download a copy of "The Love Guru." But, as is usual, Linux users have OS control options that just aren't available to Windows and MAC users.


For Linux users can apparently block the fake reset packets most commonly employed to throttle BitTorrent by employing a simple rule found in the Linux iptables.


From TuxTraining:



If you are using a Red Hat Linux derivative, such as Fedora Core or CentOS, then you will want to edit /etc/sysconfig/iptables. First, make a backup of this file. Next, open this file in your favorite text editor. Replace the current contents with this, substituting 6883 with your BitTorrent port number:


(Note: the values state, reject, dport and tcp-flags begin with a double dash )


*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

-A INPUT -i lo -j ACCEPT

#Comcast BitTorrent seeding block workaround

-A INPUT -p tcp –dport 6883 –tcp-flags RST RST -j DROP

-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

#BitTorrent

-A INPUT -m state –state NEW -m tcp -p tcp –dport 6883 -j ACCEPT

-A INPUT -m state –state NEW -m udp -p udp –dport 6883 -j ACCEPT

-A INPUT -j REJECT –reject-with icmp-host-prohibited

COMMIT


Reload your iptables firewall with service iptables restart. You should now see a great improvement in your seeding.


If you are using Ubuntu or another non-Red Hat Linux derivative, then place the following in a file and execute that file as root.


#!/bin/sh

#Replace 6883 with you BT port

BT_PORT=6883

#Flush the filters

iptables -F

#Apply new filters

iptables -A INPUT -i lo -j ACCEPT

#Comcast BitTorrent seeding block workaround

iptables -A INPUT -p tcp --dport $BT_PORT --tcp-flags RST RST -j DROP

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#BitTorrent

iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport $BT_PORT -j ACCEPT

iptables -A INPUT -m state --state NEW -m udp -p udp --dport $BT_PORT -j ACCEPT

iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited


If you are using Gentoo or another distro, it is important that your iptables rules includes this line, feel free to change the port number (or make it a range of ports).


-A INPUT -p tcp –dport 6883 –tcp-flags RST RST -j DROP


Your firewall is now configured and you should have great upload speed now. You will have to run this script every boot, by the way. One easy way is to call the script at the end of /etc/rc.local.



Let me know if you find it successful.


(jared@zeropaid.com)




  • #1    A lot of this is totally incorrect.

    For one thing, this won't really beat Sandvine (the P2P throttling system Comcast uses) until everybody does this. All this workaround does is drop the RST packets on the port BitTorrent is running on. The theory is that if you ignore the RST packets, the connection won't be reset and you can keep seeding. Problem is, Sandvine sends RST packets to both people. You won't reset the connection, but they will. It only works if both ends of the connection have applied the fix. It's great if people try doing this, but it seems doubtful that it will improve speeds much.

    Oh, and also, what makes you think Mac OS X/Windows can't do this? I don't appreciate the wild Linux fanboyism. Mac users can use the same fix with the pre-installed ipfw (the BSD/Mac equivalent to iptables), a tutorial can be found at http://wakarimasu.googlepages.com/macosx. For Windows users it is more difficult and involves installing software--WIPFW (the Windows ipfw). A tutorial can be found at http://wakarimasu.googlepages.com/windows.

    Anyway, it's rather unlikely to help as I said earlier. There's no chance of a community effort large enough to make the RST block useful. Comcast has said it will stop protocol-based throttling fairly soon, if one didn't trust them or didn't want to wait I'd suggest changing ISPs or waiting for the BitTorrent protocol extension that willl make Sandvine useless (see http://bittorrent.org/beps/bep_0008.html).
    posted by Hunted Charlie 138 days 16 hours 11 minutes ago
  • #2    With all due respect, I think Jared talking about Linux in one news article is not classified as 'wild Linux Fanboyism' in my books. Besides, there is no harm in saying that it works on Linux as far as I know. In the mean time, the links are appreciated. Jared correctly notes that Linux users have controls over their OS that simply aren't offered on Apple and Windows (being open source alone makes this a correct statement)

    Besides, isn't protocol-based filtering based on header packet information? If so, most p2p encryption i.e. eMule protocol obfuscation has already worked around this (and has implemented KAD encryption as well on top of it) A study showed that eMule was difficult to impossible to detect on a network when it's content is encrypted (I wrote about that some time ago no less)
    posted by DrewWilson 138 days 11 hours 55 minutes ago
  • #3    Yes Drew, the problem is, as Charlie stated, the article says 'to beat sandvine do this' when it does nothing of the sort. Also, sandvine, as it's the focus of the article, doesn't work by headers, so PE is worthless against it.

    Also, being open Source means relying on trust, often the trust of no-one, as everyone is trusting someone else to do something. This was elegantly displayed a month or two back with an open source firefox plugin, which had a trojan. mozilla were distributing it, and everyone assumed someone else had checked it. The trojan was there for MONTHS before someone actually checked it. The web of trust requires there to be someone to trust, and someone to take responsibility, both of which open source is generally lacking in. That's why it's adoption is still so low.
    posted by Ben Jones 137 days 18 hours 18 minutes ago
  • #4    Open source also brings in a level of trust. This was also clearly demonstrated in the eMule community with leecher/fake mods. All the mods are suppose to be open source, but typically when someone creates a mod that damages the network, they usually make it closed source because they have something to hide.

    Plus, do you really find Windows more trustworthy because it's closed source - particularly with the rise of trusted computing?

    I respectfully disagree that something being open source means relying on trust because closed source is basically the same thing (I argue that something closed source means relying on trust much more than something that is open sourced because it's more difficult to verify and check)
    posted by DrewWilson 137 days 17 hours 41 minutes ago
  • #5    First of all, this isn't a discussion about Open Source...and that's a gigantic red herring here I'm going to ignore.

    Next, modern Linux distros are far, FAR safer than windows with regards to virus and malware infection so safety is also a red herring.

    Lastly, 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. Just provide an e-mail addy and I'll zap it off.

    Better yet, I'll put up a video on YouTube for the world to see and update this later. It really works! BELIEVE IT!
    posted by dertyz 128 days 11 hours 43 minutes ago

Login to ZeroPaid.com
Username
Password

* Be sure that you have cookies enabled in your browser, without them you will not be able to login correctly.

Register here if you are not a member of Zeropaid.com.

members that voted for this story

    © 2000 - 2008 Zeropaid Inc, All rights reserved.
    Company Info | Contact Us | Zeropaid Crew | Advertise | Cheap Cars
    Hosting Provided by:
    San Diego Colocation - Complex Drive