OBDII Wi-Fi Hacking

There are plenty of these OBDII WiFi modules advertised for sale on eBay. I’ve recently bought a RenaultSport Clio which has an OBDII port, so I picked up one to experiment with.

This little gadget plugs into the OBDII port in the Clio (which is hidden behind a removable panel just below the ignition card key slot). It creates an ad-hoc WiFi network and listens on a TCP port for client connections.

The chip that does all the hard work of connecting to the car’s onboard computer(s) is an ELM327-compatible, which means it speaks a simple ASCII protocol. Control messages are sent to the chip using old-school AT commands (like old-school modems), and OBD comms use simple hex strings.

Here’s a quick example:

>ATZ
ELM327 v1.4
>0100
41 00 9E 3E B8 11
>0120
41 20 80 00 00 00
> 0105
41 05 48

The ATZ command resets the interface chip (and displays its ID). The rest of the commands all request data from the ECU using OBD mode 1.

0100 and 0120 enumerate the OBD PIDs supported by my car. The data returned is a header (41 00 / 41 20) followed by the actual data as a bit-encoded set of flags.

0105 queries the ECU for the current engine temperature (which, in this case, returns a temperature of 32°C).

I’m going to carry on hacking with this module, and I’m hoping to build a natty little iOS telemetry app to use with it. Stay tuned for further blog posts as I learn more!

Graceful server shutdown with node.js / express

howmanyleft.co.uk runs its node.js workers behind supervisord. To avoid dropping requests with 502s when restarting workers, I hook into the SIGTERM signal and call close() on the HTTP server. This stops the server from listening for new connections, and once all the open connections are complete, the worker exits.

Here’s a quick example:

var http = require('http');

var app = http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  setTimeout(function () { res.end('OK\n'); }, 5000);
});

process.on('SIGTERM', function () {
  console.log("Closing");
  app.close();
});

app.listen(3000);

Since I’m using redis on howmanyleft, I need to close my redis connection gracefully too. The close event on the HTTP server fires when all connections have closed, so close my redis connection there (node_redis flushes all active redis commands when you call quit, so you don’t lose any data).

var http = require('http'),
    redis = require('redis').createClient();

var app = http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  setTimeout(function () { res.end('OK\n'); }, 5000);
});

process.on('SIGTERM', function () {
  console.log("Closing");
  app.close();
});

app.on('close', function () {
  console.log("Closed");
  redis.quit();
});

app.listen(3000);

Debian Wheezy Killed My Pogoplug

After months of running a hybrid sarge/wheezy installation on my Pogoplug (the wheezy bits needed for OS X Lion Time Machine support in netatalk), a power cut forced a reboot. Unfortunately the poor thing never came back to life.

A prod with an FTDI cable on the Pogoplug’s serial headers retrieved the following console grumbles:

udevd[45]: unable to receive ctrl connection: Function not implemented
udevd[45]: unable to receive ctrl connection: Function not implemented
udevd[45]: unable to receive ctrl connection: Function not implemented
udevd[45]: unable to receive ctrl connection: Function not implemented
udevd[45]: unable to receive ctrl connection: Function not implemented
udevd[45]: unable to receive ctrl connection: Function not implemented

It seems a package update had introduced a version of udevd that the poor Pogoplug’s kernel isn’t able to support. The good news is that you don’t really need the debian-installed udevd daemon. The initrd image that the Pogoplug boots from has its own, older udevd which is capable enough.

Plugging the pogoplug’s root disk into a Linux laptop and disabling the udevd daemon (insert exit 0 somewhere near the top of /etc/init.d/udev) brought my Pogoplug’s back to life, and it’ll hopefully mean I don’t have to consider a more expensive NAS for a long time yet. Yay!

Make TimeMachine in OS X Lion work with Debian Squeeze (stable) netatalk servers

All you need to do to get TimeMachine running again is to install the netatalk package from unstable. It’s a really simple process. First add the wheezy (testing) repository to your apt configuration.

# /etc/apt/sources.list
# stable repo
deb http://cdn.debian.net/debian squeeze main
# new testing repo
deb http://cdn.debian.net/debian wheezy main

Then give your squeeze repo a higher priority to your wheezy one (to prevent wheezy packages being accidentally installed when they’re not wanted).

# /etc/apt/preferences.d/priorities

Package: *
Pin: release a=squeeze
Pin-Priority: 700

Package: *
Pin: release a=wheezy
Pin-Priority: 650

Now install netatalk, making sure to tell apt-get to get it from the wheezy repo.

sudo apt-get install netatalk/wheezy

And remember, if you’ve added an afpd service description to your avahi-daemon configuration, remove it and restart netatalk (because netatalk 2.2beta will register itself automatically with avahi).

Happy Lion-ing!