Building OpenTX on Gentoo

I just got a Turnigy 9XR radio for a new quadcopter. I had been thinking about the Parrot Beebop, but I decided that I wanted a grown-up quad, so I got the AeroQuad Cyclone kit instead.

Now, the reason I bought the Turnigy 9XR is that it has an ATmega on board with fully customizable firmware. It even has the standard Atmel ISP port for programming.

I setup my laptop to build one of the major FOSS firmwares out there, OpenTX. Building the firmware itself went fine. The tricky part was building Companion, which is basically a big GUI wrapper around avrdude for burning the firmware. I hit an error that I couldn’t quite figure out:

This turned out to be because my Gentoo system was setup with python3.3 to be hit by default, and the code above is still on python2.7. I still had a build of 2.7 available, though, so it was an easy matter of switching:

Then follow the rest of the Companion build instructions, and switch it back to python3.3 when you’re done.

Coding for 80 characters per line — it’s not just for old farts anymore

In a discussion on /r/coding, people once again debated the merits of the old 80 character per line rule. My usual argument is that we want to put several code windows next to each other, so yes, we do want to limit things to 80 characters. The author of the linked piece mentions this, but I don’t think he makes a persuasive counterargument.

I might have changed my mind as 4K monitors become standard, but then someone in the discussion linked this:

This suggests that you should limit things to 50-100 characters per line for typographical reasons. Now, they’re mostly talking about prose writing there rather than code, but lacking studies otherwise, setting the limit to 80-100 seems sensible no matter how big monitors get.

GStreamer1 and Device::WebIO::RaspberryPi

Previous versions of Device::WebIO::RaspberryPi grabbed still images from the camera by calling out to raspistill. Given the limitations of the Rpi, this meant it had to load a program off the SD card into main memory and execute.

Meanwhile, the GStreamer framework has a plugin to read from the Rpi camera on its own. Problem was, the existing GStreamer module on CPAN was compiled against the deprecated 0.10 API, and rpicamsrc wouldn’t work against it.

I ended up asking around about 1.0 API bindings on the gtk2-perl list, and they were very patient in walking me through how to create them using Glib::Object::Introspection. Creating the bindings themselves was easy; hard part was figuring out all the magic it did behind the scenes to link to the C libraries and build Perl classes out of them.

After getting all that worked out, I released GStreamer1 on CPAN (the version number in the module name follows convention from Gtk2). Short on its heels, Device::WebIO::RaspberryPi 0.006 was released, which uses GStreamer1 to grab camera data for still images.

This greatly improves the wait time for grabbing an image in Device::WebIO::RaspberryPi. It also neatly solves a problem I’ve been struggling with since building the WumpusRover, which is that it was hard to reliably get images off the Rpi camera via Perl. With better Gst bindings, I think this is finally nailed down.

Keep WiFi Alive on Raspberry Pi

So solving my connection problems to a Pi by turning off power savings didn’t work. I’m now using a crude but effective method where the Pi pings the gateway every 2 minutes.

Start by adding this script to /etc/

This script works in an infinite loop, sending a single ping every 120 seconds. Call chmod 755 /etc/ to make it executable. Next, call it from /etc/rc.local:

Which will run the script on the next reboot. Call /etc/ & in a shell to start it running, and you’re done.

So far, this seems to make ssh connections start immediately every time. I’d like to figure out what the actual problem is, but this will do.

Fix for Unresponsive Raspberry Pi?

After letting a Raspberry Pi server sit for a while, I would often try to login over ssh and get a “Read from socket failed: Connection reset by peer” message. Pinging it would also fail, until about 20 seconds later. Then everything was fine.

(If this happens to you, the first thing you should check is your power adapter. If you grabbed an old cellphone charger, it might not be good enough. I like using the CanaKit 1A chargers.)

I suspect this is due to the power saving mode on USB (it’s a USB WiFi adapter, and I believe the Pi’s built-in ethernet is also handled over USB). Sure enough:

power/control . . . The default for all devices is “auto”, which means that they may be subject to automatic power management, depending on their drivers.

I set this to /etc/udev/rules.d/50-usb_power_save.rules:

Which will stop the kernel from signalling the device to go into powersaving mode. If power is a concern, then you might want to add parameters to filter the specific USB vender ID for your USB device. Or just leave it on auto mode and put up with the delay.

Not 100% sure this is the real problem, but I'm hopeful.

Update: nope, that didn't do it.

Running Apache files on a Raspberry Pi ramdisk with mod_perl

When used as a web app server, the Raspberry Pi often hosts a small number of static files that rarely change. Although the Raspberry Pi Model B(+) only has 512 MB of RAM, using 10MB for a ramdisk is usually more than enough.

Files will be copied by Apache at startup. If you make changes to these files, you’ll either need to copy them manually, or restart Apache.

Start by making the directory mount point. I used /var/www-ramdisk:

Modern linux systems mount ramdisks through ‘tmpfs’, so add an entry to /etc/fstab:

Replace [UID] and [GID] with the respective uid and gid that Apache runs under for your system. On the default Raspbian install, this will be the www-data user and group.

Run mount -a and the ramdisk should appear (use df to confirm).

Next comes the Apache config. Somewhere in the config, you’ll need a PerlConfigRequire:

Create /etc/apache2/, an write in:

This shells out during startup to recursively copy everything from the default Apache docroot to the ramdisk.

Now grep through your Apache config, and change all paths to /var/www and replace it with /var/www-ramdisk. Lastly, restart Apache with:

Check the files with ls -l /var/www-ramdisk and you should see everything that’s in /var/www.

Edit: Forgot to credit, where I got much of the fstab setup.


“use strict” makes us forget that Perl used to be worse

What does “int a, b, c” do in Perl? Lots of people want to say that this won’t even compile. There’s even a comment on the StackOverflow post accusing OP of posting uncompilable code.

It is compilable. Without use strict, perl will accept damn near anything. What’s interesting here is that the immediate response by many people is that it’s invalid code. That was my initial reaction, and it took me a second to remind myself.

It’s interesting that we’re all so conditioned to use strict that we forgot how Perl looks without it. This is probably a good thing.

Considering the Security of SSL Client Certs Versus HTTP Basic Auth

People often overlook this option, but SSL allows clients to have their own certificates for authentication. It’s similar to SSH key authentication, except because it’s SSL, it’s mind-numbingly complicated to setup. For optimal results, you’ll want to have one client cert for each desktop, laptop, tablet, etc. that you want to connect to the site.

Tablets and smartphones are particularly tricky, because they can be stolen so easily. If you have a client cert loaded, my Galaxy S5 forces you to use at least a pin code for unlocking the phone. Sensible, but also more awkward to use.

Given that I was working on an HTTPS site, I wondered how the security of a long, random password (using basic HTTP auth) would be compared to SSL.

Basic auth is transfered in plaintext. The HTTP protocol does support digest encryption for plaintext connections, but that’s unnecessary for SSL.

On the server side, basic auth passwords can be stored in encrypted form. Apache’s default htpasswd uses either MD5 or crypt(), neither of which is adequate.

What about the security of the authentication handshake? Consider that SSL initiates connections with public key crypto, but for performance reasons, it uses that connection to transmit a newly-created, random block cipher key. The server and client negotiate for the specific block cipher, but it’s probably going to be AES128, or maybe something else of around 128 bits.

Therefore, transmitting a password with 128 bits of entropy will be just as secure as AES128. That is, if the password were stronger than this, then an attacker would have an easier time attacking the block cipher rather than the password.

So what do you need to get to 128 bits of password entropy? It’s a function of how many characters are allowed in the password, and its total length. Since we’re talking about characters that can be typed on a keyboard (whichever kind is standard in your country–US for me), we aren’t using the complete space of an 8-bit byte. So we need to get out some math:

Where H is the bits of entropy, L is the password length, and N is the number of characters that you are allowing in your password.

Here’s 90 characters that can be typed out on a US-standard keyboard:

Run that through the formula, and you find that a 20 character password will get you about 130 bits of entropy–more than AES128. If you’re considering against AES256, then 40 characters will go to 260 bits.

Given that, I wonder if it’s even worth it to use SSL client auth over HTTPS. Apache’s password storage needs modernizing, but that can be handled with server modules.

Device::WebIO Family Version 0.002

A little while ago, I made a tentative release of Device::WebIO. That was a basic version so I didn’t talk much about it. I’ve now finished up what I wanted for v0.002, which gets things to where I want.

Device::WebIO provides a unified API for controlling all the wonderful System on a Chip hardware that’s been coming out of late. If you wanted to control one of these devices on Perl previously, you would have used HiPi for Raspberry Pi, Firmata for Arduino, or Device::PCDuino for PCDuino. Each of these has their own API. With Device::WebIO, you use a single interface with a driver for your specific device.

The project borrows from WebIOPi, a Python project which is specific to the Raspberry Pi. What I really liked about it was the REST interface, which lets you control the pins over a web browser. But I also wanted to branch out from just the Raspberry Pi, and hey, I also prefer Perl.

So I grabbed the REST interface and implemented in Device::WebIO::Dancer. It’s mostly compatible with WebIOPi’s interface, but I made a few changes where it tended to be too specific to the Raspberry Pi. For instance, Analog-to-Digital Converters need a voltref and a bit resolution. On the Rpi (or rather, expander boards for the Rpi, since it doesn’t have an ADC pin on its own), the voltref and resolution values are the same across all pins, but that’s not true on the PCDuino. The original interface didn’t specify such a pin, so I added a pin value to the call.

All such changes are documented in the pod for the REST API.