Stories from an Opentracker running an open bittorrent tracker Fri, 04 Mar 2011 12:35:50 +0000 en-US hourly 1 Recent fuzz about the tracker Fri, 04 Mar 2011 12:27:51 +0000 taklamakan There is some fuzz about our tracker in the recent days. Some people claim that the Chaos Computer Club started a tracker which, in their terms, is the successor of

And they all got it so wrong.

First of all, the Chaos Computer Club is running their own BitTorrent trackers for a really long time. Sometimes they call it, sometimes They use them to distribute their congress recordings, the recordings of their Radioshows or Podcasts and maybe even for some Open Source stuff. Why they created to many? Because its so easy with opentracker!

Now they created another one which is called and somehow someone jumped to conclusion that this is the real deal and the official successor of! Well its not.

Second of all, started as our tracker to develop the opentracker software, it wasn’t intended to become one of the largest trackers in the world. But it did and both the tracker and the software became a huge success, also because we could test the software with a huge amount of hashes and peers!

Some people got in really bad trouble for that, even if they didn’t have to do anything with this.

Partly because of that, but also because we don’t have the resources and time to operate one of the largest trackers in the world anymore, is dead.

If you liked denis.stalker and want it back, feel free to register your own domain and/or create a denis.stalker.your.domain record in your domain and point it to!

Nevertheless, we like the fact that the CCC is using opentracker as their tracker software of choice and if you have any CC-licenced or open source stuff, feel free to use their tracker!

]]> 2
Flattered by pirates Thu, 05 Aug 2010 13:53:36 +0000 erdgeist The beerware license – most famously used by Poul-Henning Kamp – originally was less about beer and more about politics. It basically meant surrendering copyrights on your software to “the kids”, helping them to understand, learn and pirate good parts of your source (in order not to reinvent it badly). In exchange, if you were one of those kids and felt like some piece of software really inspired you, or if you could save some time and work by using this software, the license encourages you to grab the developer in question, invite h** for a beer or two and talk. Give feedback, discuss ideas, point out rooms for improvement and reiterate the fact that the software actually is in good use. IOW: flatter the developer by dedicating a short amount of your time.

While the beerware license was better known in the BSD scene only, the opentracker project can claim to have introduced it to the pirate scene. There the basic concept shifted away from dedicating the user’s time to dedicating a certain amount of beer to show appreciation. Although we were not exactly sad about this development, it led to incidents where people sent us beer from overseas without ever intending to drink that beer with us. Now – beer from the U.S. is an experience from the beginning and won’t turn out better once it arrived in europe (:

So, until now there was no appropriate way to show your support remotely. Wiring money to pay for a beer means to waste a crate worth of beer just for the fees. With the advent of the flattr service there is now hope on the horizon to be part of a crowd that shows up at a party with a keg of beer. That doesn’t mean that you should not try to engage in giving verbal feedback whenever possible, but it means that you can now actually fill up your favourite bittorrent tracker team from your couch.

Depending on the amount of money that accumulates on the opentracker flattr-thing, we will engage in a variety of drinking games ranging from silently getting a booze sharing one very cheap bottle of Sternburger to throwing a barbecue party with several kegs of our favourite bavarian brew. There will – of course – be video documentation of how we bring your flattrs to good use.

Find opentracker as a flattr thing here.

]]> 4
Norwegian State TV Launches its own BitTorrent Tracker using opentracker Sun, 08 Mar 2009 21:24:54 +0000 taklamakan We are proud to announce that the Norwegian State TV Launches its own BitTorrent Tracker and they are using the opentracker software!

Maybe we will get a barrel of norwegian beer some day? :-)

Seems like the Norwegian State TV has understood what their viewers want, to quote Torrentfreak: “NRK understands that the traditional distribution methods are changing, and that their viewers want to consume television shows wherever and whenever they want. The way people consume music and video has changed, and NRK doesn’t want to fall behind.”

Hurray for Norwegian State TV!

]]> 8
Beerware dreams Thu, 01 Jan 2009 17:10:41 +0000 erdgeist The opentracker team wants to thank Berlin’s pirate party (Piratenpartei Berlin) for their encouragement in the development of opentracker which they showed in form of a 50 Liter barrel of delicious bavarian beer.

With the heroic and sacrificially help of many Congress Angels we finally managed to spend all the beer and have – to our best knowledge – not introduced any bugs due to the consumption.

So hohoho to the pirates and a happy 2009 to everyone.

]]> 1
Still alive and kicking… Sun, 28 Dec 2008 01:14:09 +0000 erdgeist For those wondering what all the silence in this blog means.

Yes, we’re still alive and kicking. Currently discussing all our proposals with client developers, which is consuming more time and energy as we thought it would. You can usually find us at IRC channel #transmission on freenode and join discussions.

We’re also preparing to introduce some real crypto into our udp protocol and trying to enforce good behaviour towards trackers. Also opentracker has been heavily refactored and will enjoy some more changes towards multi threading capabilities due in january 2009.

So stay tuned. And to all opentracker users: a happy 2009!

]]> 0
auto-UDP up and running Wed, 11 Jun 2008 21:23:21 +0000 supergrobi In our last post we made the advise to use some sort of auto-UDP because it would also help to lower the trackertraffic for EVERY torrent even if they have an HTTP announce URL.

We can now (a little late, but not without a little pride…) announce that Azureus has support for auto-UDP since version (they revised it a little in So it seems to work and we would like to suggest others to follow their steps. Every big tracker admin loves that and will be grateful.


]]> 3
The UDP situation Tue, 01 Jan 2008 23:18:09 +0000 erdgeist Most of the problems we have to cope with in our everyday opentracker struggle arises from operating systems having to handle several thousand tcp connection setups, reassembly and tear downs. As a mean to help ease the impact of these requests, a udp extension to the tracker protocol has been agreed upon.

However that specification page does a rather poor job – besides of the obvious html layout deficiencies – when it comes to explaining what design decissions were made and why. This lead to many client writers out there wondering what the connect packet is about.

While there are sites around with a layout that at least does not try to prevent implementation, rationale for the extension completely is absent.

1. The connect packet

Now, what is the extra connect packet all about? Wasn’t the udp extension all about saving packets hammering the server? The answer is, it was designed to prevent address spoofing. While tcp inherently prevents address spoofing with its initial handshaking – you can only finish it if the recipient of SYN+ACK is the same address that sent the SYN – udp does not provide any means of ensuring that the packet really originated from the address it claims to be.

So Olaf van der Spek – designer of that protocol extension – demands that a client first uses a connect packet to acquire a uniq-ish connection_id that it later presents to the tracker to prove listening on that very address.

What way of chosing, storing and comparing connection_ids a tracker implements is up to him, one possible way would be chosing one very long global tracker secret, and then calculate a cryptographically secure checksum of this secret appended by the clients alleged ip address. This approach would not require the tracker to store anything per client for it can be calculated everytime that client comes back.

However, when writing the specification, Olaf made the mistake of not mentioning this feature and – even worse – using the term connection_id for two completely unrelated values: A connect packet contains a static protocol identifier at the same offset where on announce and scrape packets that unique connection_id is expected. Olaf even also calls that value connection_id. Hence half of the non-connect udp packets arriving at opentracker still contain 0×41727101980 as connection_id.

To be honest, opentracker is not completely innocent. Since we could freely chose which values to put there, we just left the old connection_id. This might have given the impression that the whole connection_id thing just is a sanity feature to distinguish stray udp packets arriving on that port.

Now we’re facing the problem that enforcing connection_id checking would really hurt udp announces. This is not in our interest. As a first step we changed our code to return a different value as connection_id. Now we want to encourage all client authors supporting udp to check their implementation against the way it was meant to be. In some months from now opentracker will enforce connection_id checking.

2. Auto UDP

As you may have guessed by now we do love udp announces a lot more than the tcp stuff. So introducing ways to increase the number of those more lightweight client interactions is in our own very interest.

We do know that it is hard to encourage users to add udp:// addresses to their torrents. Still most tracker responses on earth are being handled by trackers that are capable of speaking udp (and soon also udp-v6). This means that sending udp connect packets to the corresponding udp port of a http tracker url will most likely succeed.

We hereby invite all client authors to probe the corresponding udp announce address, store the result on a per-tracker base, use udp whenever feasible (i.e. for announces and [non-full-]scrapes) and revert to tcp only if udp fails.

3. IPv6

And while you are at it: you might also want to take a look at our v6 protocol extension proposal.

As always, feel free to comment on that topic at our coders mailing list.

]]> 3
The IPv6 situation Fri, 28 Dec 2007 21:48:09 +0000 erdgeist If you haven’t spent the last decade behind a C64 you may have noticed a HugeNewThing™ called IPv6 is coming. There still are some issues that prevent its wide spread use. No consumer DSL has it. Most people wouldn’t even care what *IPv4* is. However, bittorrent has been designed to work with IPv6 out of the box. Many convenience extensions in the Bittorrent-Tracker protocol – compact tracker responses, for example – do not. Worse: others like the UDP-Tracker protocol do not even look like having taken IPv6 into account at all.

Still, we consider IPv6 very important and convenient. Its use could solve all NAT-dependent connectivity issues and heavily reduce complexity in clients. On the other hand we noticed that introducing IPv6 in a transitional way creates many headaches in inter-protocol communication. To remove some barriers we propose the following request for comments which will be incorporated into opentracker and thus available at tpb soon.

1. The clouds

To be frank: there will be two clouds for each torrent, one in IPv4 and one in IPv6. Clients capable of handling IPv6 connections and still interested in IPv4 peers will need to announce their torrents to trackers twice. This is a harsh decission, but in the end most IPv4 peers are not interested in IPv6 peers and there is no easy way to tell whom to return which peers.

The proposed way to identify a peer’s internet protocol version defaults to the incoming socket address and can be overridden by the ip parameter from the announce http request.

This is very much how Bram Cohen layed it out in his Tracker-Protocol. Of course, overriding only works for trackers that allow overriding ip addresses with the one passed in the query. All others have no means of obtaining the ip address for the other protocol version.

Scrapes will be answered for each cloud independently according to the requestors ip address protocol version.

2. Tracker TCP Responses

Most trackers (e.g. opentracker) have completely switched to only returning compact responses in order to save, or better: not to waste bandwidth. That compact format is just a string of multiple of six bytes that contain ip address and port for as many peers as do fit there. Filling it with or mixing in IPv6 addresses is impossible without breaking backward compatibility.

So we propose adding another “peers6″ entry in the announce response dictionary that contains a string of zero or more entries, each 16 bytes network byte order IPv6 addresses followed by 2 byte network byte order port number. The “peers6″ entry must not be present in non-compact mode.

3. Tracker UDP Responses

The UDP-protocol has not left any space for IPv6-addresses in its current form. So we need to define a new action together with its input and output block formats.

Proposed extension to the UDP Tracker format to work over IPv6, we claim a value for the action identifier of “4″.:


Offset Size Name Value
0 64-bit integer connection_id
8 32-bit integer action 4
12 32-bit integer transaction_id
16 20-byte string info_hash
36 20-byte string peer_id
56 64-bit integer downloaded
64 64-bit integer left
72 64-bit integer uploaded
80 32-bit integer event
84 16-byte string IP address
100 32-bit integer key
104 32-bit integer num_want -1
108 16-bit integer port

The corresponding reply looks as follows:


Offset Size Name Value
0 32-bit integer action 4
4 32-bit integer transaction_id
8 32-bit integer interval
12 32-bit integer leechers
16 32-bit integer seeders
20+n*18 16-byte string IPv6 address
36+n*18 16-bit integer TCP port

We consider those the most sane design decissions that do not deviate from existing protocol too much and hope to receive feedback on our proposal, from closed source implementations as well as the usual open source suspects.

]]> 8
Going social Fri, 28 Dec 2007 02:42:52 +0000 erdgeist This topic is only for our German readers, sorry ’bout that.

Wir sind nun auch audio-visuell in Erscheinung getreten und haben unser opentracker-Projekt und Bittorrent im Allgemeinen in einem Chaos Radio Express mit Tim und einem Talk über opentracker auf dem 24C3 vorgestellt.

Wenn es das Video gibt, reichen wir den Link nach.

Update: So jetzt gibts auch das Video, natürlich als torrent: 24c3-2355-de-trecker_fahrn.mkv oder 24c3-2355-de-trecker_fahrn.mp4

]]> 8
Review-A-Tracker-Team Tue, 11 Dec 2007 00:49:07 +0000 erdgeist Six days ago – on December 5th – opentracker celebrated its first birthday, just two days before officially becoming the tracker handling most tracker requests on earth. During that year openracker already handled several billions http connections in what can only be described as the hardest fuzzing attack ever done to a software (:

However, becoming so huge and being so exposed brings its risks. opentracker is written in plain C and handles strings. Strings that have been sent through the internet. So we kindly ask the community to help us make the code more secure by reviewing critical parts of it. Especially the part that parses URIs is a natural point to start looking into.

So if you are experienced in C, serious about helping to review or just need some explanation on opentrackers rougher edges, feel free to contact us at We do also appreciate patches that fix bugs and warnings on operating systems we have not tested opentracker on and source packages for certain package distribution systems.

]]> 3