Headless Azureus on FreeBSD 6.1

I want to run the popular Azureus BitTorrent client on bonzo, which has a ton of bandwidth to burn. Bonzo is a virtual machine on a rackmount server in a data center, so I need to run Azureus in headless mode, using its HTML UI to control it from afar.

I’m starting with a freshly upgraded FreeBSD 6.1-RELEASE box.

First, I’ll need to install Java 1.5. As it happens, Sun and the FreeBSD team have finally come up with an official Java release for FreeBSD. I downloaded the package for FreeBSD 6, and installed it with pkg_add.

Upon doing so, I got:

 bonzo# pkg_add diablo-jdk-freebsd6-1.5.0.06.00.tbz
 pkg_add: could not find package javavmwrapper-2.0_5 !

There’s a port called javavmwrapper in java/; I’m installing that.

After running pkg_add again, it worked with this warning:

 pkg_add: warning: package 'diablo-jdk-1.5.0.06.00' requires 'javavmwrapper-2.0_5', but 'javavmwrapper-2.0_7' is installed

No big deal; this package was for FreeBSD 6.0, and I’m running 6.1; inshallah they’re compatible.

Sure enough:

 bonzo# java -version
 java version "1.5.0"
 Java(TM) 2 Runtime Environment, Standard Edition (build diablo-1.5.0-b00)
 Java HotSpot(TM) Client VM (build diablo-1.5.0_06-b00, mixed mode)

Now I’ll download Azureus. Since I’m not running Windows, I’ll want the jar download.

I also need a couple additional JARs in the classpath to make this work. After downloading them into the same directory as the Azureus jar file, I ran:

  $ java -jar Azureus2.4.0.2.jar --ui=console

as per instructions. Sure enough, Azureus came right up. In fact, right off the bat it reported a few updates available:

 Update available for 'Core Patch Checker', new version =
 Update available for 'azupdater/Azureus Updater Support Patcher', new version = 1.8.3
    Normally installed via auto-update.
    This plugin contains support for restarting azureus when upgrading.
        ...
 Update available for 'Platform-specific support', new version = 1.11
    Normally installed via auto-update.
    This plugin contains platform-specific support for Azureus. For windows this includes file association support and Azureus.exe.
    To manually install this plugin, unzip the files into the Azureus program location, ensuring that the OS-specific path within the ZIP file is removed.
        ...

Unfortunately, neither the Console UI Help nor Google have any insight into how to auto update from the console UI, so I guess I’m screwed for the time being.

Moving on, I need to configure Azureus’ bandwidth limitations. Bonzo is plugged into a Fast Ethernet switch which ultimately links it to multiple redundant fiber backbones, however I’m limited to 5TB/month of transfer, and I don’t want to burn it all on Azureus. So, I’m thinking a 500kb/s up limit is reasonable.

 set Core_iMaxUploadSpeed 500

I also want to override the file system locations where torrents and downloads go:

 set General_sDefaultSave_Directory /home/anelson/downloads
 set General_sDefaultTorrent_Directory /home/anelson/torrents

Next I’ll install the HTML UI plugin. Installing it was easy; I downloaded the JAR from the HTML UI page and copied it to the plugins directory under the directory where I extracted the Azureus JAR.

Configuration of the plugin becomes tricky, as it doesn’t have any visible options when I run set to list available parameters. In fact, I don’t think the plugin is being loaded; when I attempt to access http://localhost:6886/ that port isn’t open. I must be missing something required to get the plugin to actually load.

Doh! I made a n00b mistake. I put the jar into the plugins folder, but the correct way to install a plugin is to create a folder for the plugin within plugins, then put the JAR in that folder. I did that and the azhtmlwebui options are now listed when I do set.

The configuration of the HTML UI is somewhat non-obvious, so I used the Azureus install on hotsoup-p2p to look at the GUI options to translate them into console config settings. I want the HTML UI to be available only via localhost, so I can use an SSH tunnel to access it but otherwise it’s not exposed. Thus, the Plugin.azhtmlwebui.Access parameter is set to 127.0.0.1. I don’t need a username or password, and the other parameters are fine at their default values.

 set Plugin.azhtmlwebui.Access 127.0.0.1

I set up a PuTTY shortcut to run this:

 "C:\Program Files\PuTTY\putty.exe" -A anelson@69.13.38.69 -L 127.0.0.3:6886:localhost:6886

This will tunnel port 6886 on 127.0.0.3 to bonzo’s localhost port 6886. Then, I can access the admin interface with http://127.0.0.3:6886/ from the PuTTY client machine.

Voila! Works like a charm.

Now I’ll download a large, legal torrent to test out my transfer performance. I suspect some meddling by my bargain-basement ISP (CI Host), and would like to explore it with a legal download rather than stir up a ToS violation on my first day. DataGalaxy.net has a decent list of legal torrents; I chose the Fedora Core ’stentz’ DVD, clocking in at over 2GB.

I got an error ‘uploading’ the torrent (it’s actually downloading, but the HTML web UI doesn’t distinguish between uploading a torrent file or specifying a URL). The error in the HTML UI interface was meaningless:

 Error loading http://www.kanava.org/~bostonarch/btit/download.php?id=87ab90f08a3dacefe69b7e0de15d88e207efdcdc&f=stentz-dvd-i386.torrent

On the console it was more constructive:

 org.gudy.azureus2.plugins.download.DownloadException: DownloadManager::addDownload: default data save directory must be configured

I knew that. The Console UI help list two parameters for that purpose:

 set "Default save path" "/home/anelson/downloads" string
 set "Use default data dir" true boolean

Splash one. Download worked now.

Well, sort of. Xfer rate is nearly nothing, and I suspect a firewall problem.

Sure enough. I ran nc from wintermute, which is on my home LAN, and got this:

 $ nc -v -w 5 bonzo.celatrix.com 6881
 nc: connect to bonzo.celatrix.com port 6881 (tcp) failed: Connection refused

So the bullshit CI Host firewall strikes again. Fortunately, I know of at least one TCP port (3389, Terminal Services) which their firewall passes. I’ll switch Azureus to using that port and try again.

 set TCP.Listen.Port 3389

Ok, how about now:

 nc -v -w 5 bonzo.celatrix.com 3389
 Connection to bonzo.celatrix.com 3389 port [tcp/*] succeeded!

Ok, so it’s no longer a firewall issue. Maybe it’s the torrent itself. I’m trying the ‘bordeaux-dvd’ as well, which has several hundred seeders.

No, it’s still running at nearly 0 kb/s. Hmm.

I thought maybe it was an outgoing firewall rule preventing requests from bonzo to tcp/6881, but then I did this from bonzo:

 nc -v -w 5 actinium.apocryph.org 6881
 Connection to actinium.apocryph.org 6881 port [tcp/*] succeeded!

So that’s obviously not it. I’ll try enabling logging, to see if that helps:

 set Logger_sDir_Directory /home/anelson/azureus/logs
 set Logger.Enabled 1
 set Logger_bEnable 1

Nothing really jumps out, but the log output a flood of messages, and the log filter parameters (like Logger_bLog0-0) are non-obvious.

I tried downloading another torrent which I’m currently fetching on hotsoup-p2p at an average of 70kB/s; on bonzo it’s not getting anything, despite multiple seeder connections. I’m beginning to suspect CI Host blockage, but I’m not giving up yet.

I’m installing BTQueue from the ports collection. BTQueue is (hopefully) a simpler client that’s more easily configured, which will enable me to compare performance meaningfully.

I couldn’t get BTQueue to work; it’s a strange tool with it’s own console and no obvious configuration files, and scarce docs. I’m trying rtorrent instead.

rtorrent is pretty easy to work with. I reconfigured it to use tcp/3389, and it suffers the same agonizing slow download problem exhibited by Azureus on bonzo. This leads me to conclude that CI Host is deliberately obstructing BitTorrent downloads, which would be egregious if true. I’ll email and ask.


After some time, rtorrent started to show decent transfer rates, at least as good as I get on my house DSL line. I know BitTorrent downloads take a while to get up to full speed, but Azureus normally gets cranking pretty quickly, and even after an hour on bonzo was still getting nowhere. For now I’ll continue to use rtorrent, though long term I’d like to get Azureus working.

The next step is to integrate the PeerGuardian P2P blocklist into either the P2P client (less desirable) or the BSD firewall (more desirable).

It looks like net/tableutil is a good candidate for this.

Unfortunately not. The PeerGuardian blocklist thing is all very obfuscated. Once I went through bullshit registration at BlueTack I was able to access their List Info Tool to get a link to their ‘level 1′ blocklist, which according to their blocklist FAQ is the list of anti-p2p addresses. But this list doesn’t seem to be available in the binary P2B format supported by tableutil; instead it’s in the text-only P2P format. I guess I’ll have to write a sed script to convert this into the lists of IP ranges which pf understands. Why is this such a PITA?

Tags: , , ,

Leave a Reply