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 torrent.ccc.de, sometimes bittorrent.ccc.de. 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 tracker.ccc.de and somehow someone jumped to conclusion that this is the real deal and the official successor of denis.stalker.h3q.com! Well its not.

Second of all, denis.stalker.h3q.com 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, denis.stalker.h3q.com 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 tracker.openbittorrent.com!

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!

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.

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!

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.

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!

We can now (a little late, but not without a little pride…) announce that Azureus has support for auto-UDP since version 3.0.5.0 (they revised it a little in 3.0.5.2). 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.

supergrobi

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.

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″.:

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

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 code@denis.stalker.h3q.com. 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.