A recent stay in a couple of Germany hotels revealed a few things: First, American cultural imperialism has spun out of control, to the point where hotel receptionists are now footsoldiers for those who claim ownership of music and movie content. One hotel owner told us he had been fined two thousand Euros for MP3s downloaded by guests. While in another hotel I was hard pressed to get a second access code on their WiFi, and was not allowed to sign for the it on behalf of my wife. No wonder the The German Pirate Party has wind in its sails.

Secondly, even without these surveillance tactics in place, connecting to the abundance of half-open WiFi networks without authenticating can be useful. They are open in the sense that WiFi encryption is not used, and you can acquire a local IP without password. Most of the time, these networks are set up with a local log-in page, which grants you access for a specific device (MAC based) typically for a fixed amount of time. However, before the authentication code and password is entered, some traffic is let through: DNS requests have to work to get to the log-in page, and local hotel page. This is the basis of several TCP/IP over DNS protocols. I choice iodine, and successfully used the hotel network without log-in.

iodine is a bespoke server/client protocol which lets you tunnel IP4 data over DNS requests/responses. It works by setting up an extra network interface (TUN/TAP device) on both server and client, so that any traffic can be tunnelled. It takes care of a lot of the nitty-gritty settings itself, and probes for best settings. Finally, iodine is available for most popular platforms, including GNU/Linux (in the default repositories of Fedora and Ubuntu), *BSD, Android. However, make sure the same version is running on both client and server, as the author states that compatibility between versions is not a project goal.

Detailed setup is covered by several people, including their own HowTo and README; a CentOS compile example; and one for Debian. Thus, I wont repeat those details, and only cover some of the gotchas I stumbled upon and lessons I learnt:

  1. Start small and expand: The client/server can be brought up on the same machine, so make sure to try that first. Then try on the same local network, or remote but open networks, and finally on a semi-open network.
  2. Watch your firewall! The default DNS port, 53, is typically blocked, so you'll have to punch through and forward that. Also make sure you open for UDP on that port! Use nmap from different locations to confirm that the port is open throughout. nc (Netcat) is useful in debugging the connection, but again make sure it's UDP.
  3. Make sure the DNS entries for your domain are correct. You need two entries, and with some providers, it might not be obvious how to fill in their web-form to achieve the exact settings. I found this example most helpful.
  4. Debug the DNS setup using the CLI command dig, and the DNS web-tool by MXTools. For dig usage, this comment was useful.
  5. Use the test page provided by the author of iodine. It gives detailed and useful error reports on how far you've come with your setup.

With some luck, you'll have a working setup, and will now be prepared for the next time the hotel receptionist does not give you enough WiFi vouchers for all your devices. Having said that, it does not really replace full access, as the connection will be "modem-slow", or even worse. However, you do get access, which is sometimes what counts.

A client is is also available for Android from iodine, and Marcel goes into details on how to compile and run. I've not tried yet, and it seems there's room for an easy to install F-Droid package there. More about that later.