Skip to main content

"A workaround for Bittorrent traffic shaping" or "bashing my ISP"

Recently, I found out that my ISP does traffic shaping with respect to Bittorrent traffic. After my clients sends the Bittorrent handshake, all packets from the respective TCP conversation were dropped, so the remote peer sees nothing of the following. That's not just a minor issue in quality of service, right? That's a breach of contract with respect to universal IP service agreements.

If you are subscribed to UPC in Vienna, this letter to my ISP might be interesting to you. Next to regular rhetoric that they should immediately stop that practice, they are also warned that otherwise I will get them in front of the national conciliation body for telecommunication (

If you are unlucky to be subscribed such an ISPs, you can use Azureus to work around that.

  • Find out your public IP and ensure that there is some open/forwarded port in your firewall/router or whatever you may have. 
  • Get and setup up and Azureus.
  • Run TOR with its Socks proxy.
  • Launch Azureus
  • Azureus-Options-Connection: Enter the public port from before as Incoming TCP/UDP listen port.
  • Azureus-Options-Connection-Proxy Options: Tick "Enable proxying of tracker communication
  • Azureus-Options-Connection-Proxy Options: Tick "I have a SOCKS proxy", and enter the host/port combination of your Tor Socks proxy (most likely localhost:9050)
  • Azureus-Options-Connection-Transport Encryption: "Require encrypted transport" with Minimum encryption level "RC4"
  • Azureus-Options-Tracker-Client: Enter your public IP/port in the "Override Options".
That's it. You are ready to go, and override ANY bittorrent traffic shaping (at least the one that listens for bittorrent signature). The drawback is that your only able to communicate with other Bittorrent clients that know encryption. But that's better than no connection at all.


Unknown said…
I just got out from under the UPC umbrella (my DSL got acquired along with inode) last month, but evil traffic shaping practices would be entirely within expectations for them.

Still, your technical description sounds a bit weird - wouldn't that lead to a total blocking of all bittorrent traffic? I think we would have heard about this before if that was the case.
Yes, that's right, bittorrent is totally blocked for me. I have two log files from my local UPC side and my own remote tracker, that clearly show that all traffic is blocked. Azureus isn't even able to contact the tracker with a direct peer connection, though ktorrent gets to the tracker, but as Azureus can't talk to any other peer. I suspect ktorrent uses a slightly different connection scheme, one which UPC doesn't listen for.
Anonymous said…
Isn't using tor with bt considered Really Poor Form?
this scheme only uses tor for tracker communications. remember, the Bittorrent tracker protocol isn't really heavy. I'd say surfing the web using Tor causes more traffic at the exit nodes. The actual transfer is still P2P, but as this scheme uses RC4 encryption, there is no unencrypted fragment in the communication a traffic shaper could listen for.
Unknown said…
Did UPC respond yet? Plz keep us updated.