Category Archives: networking

Getting started with the Arietta G25 board

This weekend, I received my ACME Arietta G25 Atmel ARM board, and tried to get it going with my Mac. I ordered the “plain” version with 128 MB RAM, as well as one with 256MB RAM, as well as Wifi boards and the DPI debug board.

After soldering in the necessary posts, I attached the DPI board and verified that my Mac has the right FT232 driver to access the console, no problems here.

I then fired up by Ubuntu VirtualBox machine and followed the instructions to build the Micro-SD-Card image. I then proceeded to boot successfully from the card.

IMG_2989

Through the console, I could get the Wifi card going; since I wanted to have support for more than a single network, I extended the configuration through wpa_supplicant.conf.

ACME has configured a Gadget driver to supply an Ethernet interface through the host port on the Arietta; in ACMEs configuration, this is set to offer both RNDIS and CDC EEM modes. Unfortunately, Mac OS X 10.9 doesn’t support either.

After some more reading, I decided to build my own kernel and modules. To get a Mac-compatible setup for the USB Gadget driver, run menuconfig, and navigate to

  • Device Drivers
  • USB support
  • USB Gadget Support (at the very bottom of the list)

For Mac compatibility, de-select the RNDIS support and the Ethernet Emulation Model (EEM) support under Ethernet Gadget.

I also chose to enable the Serial Gadget and the CDC Composite De
vice (Ethernet and ACM).

After building the kernel and replacing the files on the SD Card, I changed the module load line in /etc/network/interfaces to load the g_cdc module instead of the g_ether module, and added an entry in /etc/inittab for /dev/ttyGS0 to also have a console through the host port.

Debugging Java proxy settings

Java proxy settings are highly annoying. On Windows and Mac, Java does use the system proxy settings, but it doesn’t necessarily understand the same syntax as say IE or Safari/WebKit for the proxy exceptions. The end result is that you keep guessing why certain services deep inside your huge web application keep failing in mysterious ways.  On other platforms, you have to configure the proxy through system properties. Restarting a web application to test out configuration changes can take a long time.

While solving the problem might not be easy, at least I can help with debugging it, with a very simple one-liner: Java Proxy Check (GitHub, direct download link).

For java.net.URL and most other HTTP client code, Java 7 uses a class that can decide on a per-URL basis which proxy should be used: java.net.ProxySelector. javaproxycheck.jar can be run  from the command line to quickly test one or more URLs and see which proxy is selected for that URL:

$ java -Dhttps.proxyHost=proxy.example.com -Dhttps.proxyPort=3128 -jar javaproxycheck.jar http://www.example.com https://secure.example.com
http://www.example.com                   [DIRECT]
https://secure.example.com               [HTTP @ proxy.example.com:3128]

On Mac OS X and Windows, Java uses the system proxy configuration; on other systems, it optionally can use Gnome settings, but by default relies on system properties being set at startup, as documented in Networking Properties, Proxies.

nsupdate woes

Over the past three days, I’ve been trying unsuccessfully to set up a fresh name server (using Ansible and Vagrant) to play around with nsupdate and some potential middleware to automate updating DNS zones. Unfortunately, I couldn’t find any good documentation on all the specifics, just a lot of how-tos that somehow all did’t really work for me. I kept getting this error:

client 127.0.0.1#60530: request has invalid signature: TSIG example.com: tsig verify failure (BADKEY)

I will upload my Ansible role for this to Github shortly, but I felt it necessary to spare the next person the pain of getting it all to work.

To use nsupdate, you need to give bind a key, associate that with a zone, and then use that key with nsupdate. Sounds easy enough, right? What all the tutorials fail to mention is that the key files and the name of the key entries in named.conf are all significant.

First, you need to decide what to call your key. It doesn’t matter for which zones you will use it, or from which hosts you will run nsupdate, but you will need to pick a name and stick to it. You can’t change it later, you will need to create a new key if you don’t like the name.

$ dnssec-keygen -a HMAC-MD5 -n HOST -b 512 mysamplekey

This will create two files. You need both of them, and you can’t change the files’ names.

Next up, you need to add the key to named.conf, and allow requests signed by that key to update a zone (or more):

key "mysamplekey" {
    algorithm hmac-md5;
    secret "base 64 encoded key";
};

zone "example.com" {
    allow-update { key "mysamplekey"; };
    type master;
    file "dynamic/example.com";
};

It is important to remember that “mysamplekey” needs to be the exact same string as from the key generation!

Armed with this configuration, you should be able to update example.com:

$ nsupdate -k Kmysamplekey+123+45678
debug yes
server 127.0.0.1
zone example.com
update add foobar 10 A 192.0.2.1
send

Download from Tivo fails with HTTP error 400

So tonight I was wondering why no new shows had been downloaded from my Tivo to my file server. Investigating my home-grown script’s log output, I  could see that all download attempts were met with an HTTP error 400 since Sunday. (My script works similarly to kmttg.)

I immediately tried in Safari, and had no problems downloading one of these shows. So more debugging was necessary. Enabling additional output for Python’s urllib2 (used for downloading the XML table of contents) and curl (used for downloading the media files) showed an unusual Set-cookie response header on all of the requests, setting a new value for the “sid” cookie. Quick recap: when you load the XML TOC over HTTPS, the Tivo sets a “sid” cookie which you need to supply to download the actual show’s file. No problem, my script was recording the cookie using cookielib.CookieJar, passing the resulting file to curl. Or so I thought. Inspecting the cookie jar I found it to be empty. How could that be?

At this point I turned to Firefox and the Live HTTP Headers extension. Interestingly, the problem was the same in Firefox, so it wasn’t a problem in my script. but was was going wrong? After some experimentation with variations of the Set-cookie header (using my internal web server and Apache’s very useful mod_asis), plus remembering the details of the cookie protocol, it became clear:

Set-Cookie: sid=542329DF12A3586B; path=/; expires="Saturday, 16-Feb-2013 00:00:00 GMT";

If a cookie has an expires attribute, and the current date and time is later than the date specified, the cookie becomes invalid, and the HTTP client should remove it and not transmit it anymore. If a server sends a Set-Cookie header with an expires attribute in the past, the cookie should be deleted. Bingo! (Safari  had an old cookie still set, so the Tivo just used that and did not remove the cookie.)

So the Tivo is apparently trying to set a persistent cookie (confusingly named “sid” as it’s not a session cookie), but doing so with a date in the past. And everything was working just fine until last Saturday! So either Tivo pushed a software update on Sunday, changing the expires date of that cookie, or it has had that date for ever, and eternity just ran out. I haven’t reverse engineered the firmware, but I would bet that someone way back when Tivo got started hard-coded the date “way in the future”, and everbody promptly forgot about it.

No word from Tivo yet, but this Tivo forum thread mentions the same broken cookie.

I managed to add a hack to my script that extracts the “sid” from the Set-Cookie header manually and hand the proper cookie value to curl for the downloads. And I got to learn about mechanize for Python!

Prepaid Mobile Data in France

For a recent two-week vacation in France, I wanted to get the netbook and the iPhones (SIM-locked) online, without having to hunt down hotel wifi or other hotspots. Unfortunately, the situation is not quite as simple as in Germany, where there’s many reasonable priced options. Here’s what I managed to find out.

Orange offers a prepaid data plan (“journée Internet max”) for 3 Euros a day, but by various accounts, it is limited to web access only (no email etc.), and might even have restrictions on the sites you can browse to. I didn’t try that. Orange also offers an iPad option.

SFR offers a special “iPhone 3G” tariff that seemed quite interesting at first: full web access as well as email, in multiple packages up to 20 euros for 20 days and 500MB. They specifically claim that it only can be used with an iPhone. To get it, you buy a pre-paid SIM card (SFR La Carte) from any of the SFR stores, and one of the iPhone 3G recharges (see the bottom of that page). The recharge is a long number that you can punch in at a voice prompt after dialling 952. I had a French speaker help me with that. At least in Paris, most of the SFR store people I’ve encountered speak passable or very good English, and they were all friendly and helpful, and did help with the activation. You then configure your device to use APN “wapsfr”, and off you go.

With the iPhone package, data connections are indeed limited, but a lot more that I originally thought: surfing was limited to the SFR mobile portal (m.sfr.fr). Whether this was due to the fact that I was using a Mifi to establish the data connection, or due to some real limitation on the part of SFR, I’m not sure, but I’ve read elsewhere that others have encountered this block as well.

Even when accessing the mobile portal, you must use Safari on your iPhone, or make your other browser appear as an iPhone. For Safari, enable the Developer menu, and change the User Agent to one of the Mobile Safari entries. I believe there’s a number of Firefox Add-ons that allow you to change the User Agent.

The good news is that email access via IMAP and SMTP worked just fine, with all our accounts configured.

To get full internet access, I used OpenVPN from the netbook to connect to my server running on one of the ports usually used for email. This way, I could move all the internet traffic through the VPN, and have full internet access from the laptop.

Finally, to be able to browse from the iPhones as well, I used tinyproxy on the netbook to enable the iPhones to use the netbook as a proxy that connects through the VPN. This gave us full internet access throughout our journey.

Getting things purchased and activated was a bit of an adventure, but was fairly straightforward in the end. I was positively surprised by the coverage (minimum EDGE, mostly HSPA), even though we went to some slightly remote places (small villages on the Loire, Mont Saint Michel). All the descriptions claimed that services were limited to “France métropolitaine”. Also, I was surprised that we seemingly didn’t exceed the 500MB limit, even though the traffic counter on the Mifi claimed we had.

I can recommend this only to people very familiar with networking technology and the willingness to spend a couple of hours in the hotel room fiddling, instead of on the streets of Paris. So plan to bring your favorite geek along for the ride 🙂

Getting started with IPv6

Getting started with IPv6 on FreeBSD with Hurricane Electric’s free Tunnelbroker service is really straightforward. Since I’m behind a residential ADSL connection, my IPv4 address changes every 24 hours, so whenever that happens, the Tunnelbroker needs to learn my new address. We’ve put up a quick how-to on the wiki on how to do that.