Category Archives: OpenWRT

An upgrade to Ubiquiti

I’ve been _extremely_ impressed with the quality of Engenius‘ products, most specifically the EOC-2610. For the 2 years that I’ve had my two units in service, I’ve had very little issue with them.

Recently my workplace ordered a batch of Ubiquiti products from DoubleRadius. Ubiquiti is loved by the WISP world, and (mostly) utilize Atheros boards – just as the Engenius products do. Both also have stock firmware that’s also based off OpenWRT. Being inspired, I purchased some equipment myself.

Part of the reason the Ubiquiti gear seems to be more popular is their excellent support and web forum. Engenius is notoriously difficult to get any answers out of. I’ve still yet to get a copy of their firmware source required by the GPL, and I gave up long ago trying to get anywhere. Luckily, the few questions I did have were answered by simply expirementing.

This weekend I began the migration to Ubiquiti. My first rollout involves a Rocket M2 and a 120 degree sector antenna. For the past few weeks I’ve been working on adding a more recent version of the excellent CoovaChilli to the device. I have located a version of the CoovaAP firmware that runs natively on a Rocket M2, however it lacked a number of features (non-Chilli related) that I was hoping for. After much searching, I’ve been able to locate a 5.3 SDK (which features AirControl and the built-in spectrum analyzer).

The AirView built in spectrum analyzer

As I mentioned, it took quite a bit of searching to obtain the SDK. According to Kevin Perry at Ubiquiti  “We’ve had to temporarily remove the SDKs from our site to comply with US export control regulations. Once approved, we will be able to continue providing SDKs. ”  I’ve not heard anything new, and that correspondence is from September of 2011.

Of course, the Internet is a not only a compendium of 140-word-or-less Tweets about what someone just ate for dinner, it’s also a giant archive of the past. And with a bit of searching, I came across the SDK still hosted (albeit hidden) on Ubiquiti’s site.

Unfortunately the latest SDK is 5.5, and not 5.3. I’ve not had luck locating it (and it does contain the patch for the SkyNet worm), so I’m working off 5.3 for the time being. I’ve locked down access to the web interface to prevent infection from the worm.

The CoovaChilli Captive Portal

With the SDK in tow, I began the work of inserting CoovaChilli into the system. Ubiquiti ensures important services stay running by having them spawned (and respawned if needed) via inittab. The stock inittab on the system is basic, handling only login and a couple of runlevel items. Prior to /sbin/init starting, the system runs a bash script /init. This in turn handles filesystem mounts, makes a handful of device nodes, copies a number of files into place, partially configures sysinit, and sets the timezone. It also calls ubntconf which gleans information from the nvram variables, prior to executing the traditional /sbin/init.

ubntconf is a closed source application, although it’s pretty easy to glean most of it’s operations by simply running strings on it (It is an ELF not a script). Depending upon nvram variables that are set, different scripts are dropped into /etc/sysinit. Additionally, items are added to /etc/inittab like this:

null::respawn:/bin/pppd eth0
null::respawn:/bin/lighttpd -D -f /etc/lighttpd.conf
null::respawn:/bin/dropbear -F -d /etc/persistent/dropbear_dss_host_key -r /etc/
persistent/dropbear_rsa_host_key -p 22

Each of these entries will respawn the corresponding service should it crash. Using their system as a model, I created my own config creator “chilliconf” to add entries to inittab for the chilli daemon, in addition to the necessary iptables rules in /etc/sysinit, and a few modifications to their use of dnsmasq (I wanted to syslog DNS queries offsite). When I later added NProbe to my firmware, I also used my chilliconf configurator to add it to the inittab.

My chilliconf configurator, like ubntconf, is called from the /init script.

One thing of note – any daemon listed in the inittab file needs to actually run in the foreground (so calling the process a daemon isn’t entirely accurate). This is for the obvious reason that the initiating process fork()s then exits – so inittab will continually respawn the service until you run out of resources.

No Strings Attached
All original functionality is still there. It's a like a cyborg version of itself.

I used the 3.6SDK version of CoovaAP as a model for my web interface. Adding a tab was fairly easy – the web interface is maintained as the ubnt-web package in the SDK. Most of the web CGI is PHP/FI (with a couple of functions added to PHP to facilitate saving configs and reading values). The code is extremely readable, and easy to figure out.

When you save your settings in the Ubiquiti web interface, you’re presented with a blue message bar asking if you’d like to test or apply your settings. In either case, you’ll be disconnected for a moment while the system reconfigures itself. This appears to be done via a call to the original /init script. The blue bar is a bit of a problem when adding a new tab to the menu.

The background image for the blue bar (msg.png) is originally  745 pixels, and the screen width is set to 790 pixels. With an added tab, the screen width becomes 866 pixels. Using GIMP I resized this image to 821 pixels.

The Blue Message Menu
Resize the blue background to fit.
  • Originally it was 745, with the original screen width of 790.
    • 790-745 = 45.
    • 866-45 = 821 — our newly resized image.

The web interface went through a few iterations before I had all the options I presently needed. CoovaChilli’s dnsdomainlocal option is problematic – causing any DNS query that returns an NXDOMAIN error for an A record to cause a redirect to the portal. Unfortunately the portal (from my experience) doesn’t properly track in this instance if the MAC associated with the request is authenticated – and redirects the user back to the UAMSERVER with the “res=notyet” variable. This means the user is prompted with a login screen unnecessarily.

In other words, visit “”, and you’re presented with a login screen even after you’re logged in.  Adding the option to disable dnsdomainlocal fixes this problem.

The CoovaChilli Tab
The CoovaChili tab (with NProbe)

By default, I have the “dhcpradius” option enabled. With this feature, when a DHCP request is received by the CoovaChilli server, it forwards the MAC address to the radius server (as both the username and password) for authentication. If it doesn’t authenticate, the system redirects the user back to the UAMServer for a captive portal login.

The North Facing Access Point
Broadcasting throught the stratosphere

For the time being, the system is a bit overkill, but the options it presents for the future are many. CoovaChilli can rate-limit individual users based on login or MAC address. This alone opens the door for a pay-for-bandwidth model. If a user is found to be filesharing (legal or not) or otherwise consuming an inordinate amount of bandwidth, they can be easily ratelimited.

I still have a few minor items to add to the firmware (including the ability to pull RSSI information per client), but in the meantime it’s been fun working with the Rocket M2. The access point is now being tested in the neighborhood.

OpenWRT on the MikroTik RouterBoard 493AH

I recently came across a MikroTik RouterBoard 493AH at work. We’d acquired the device among numerous other pieces of equipment from a now defunct wireless ISP.

It smells of Goo-Gone and looks to have dandruff.

The 493AH features 9 ethernet ports, can accept POE on its WAN interface, has 64M NAND,  128M RAM, and can support 3 mini-PCI cards. Configuration can be performed via a serial interface and there is an external power connector available if POE isn’t used.

The device itself wouldn’t boot, only hang at the RouterBoot bootloader. Attempts to boot the NAND image failed, but the bootloader gives an easy option for downloading an image to it via TFTP.

MikroTik Logo
A brand that's loved by WISPs

Looking around, it appears the 493AH is an Atheros AR7161 .. an architecture readily supported under OpenWRT. Sure, I could just re-install RouterOS… but let’s do that later.

To install OpenWRT to the 493AH, first format the NAND. This can easily be done via the bootloader (option e):

Waxing the memory

Next, use subversion to check out the Backfire version of OpenWRT:

mkdir ~/svn/

cd ~/svn/

svn co svn:// backfire

Building the image is fairly easy, all configuration is done via a “make menuconfig“. First, we’ll build a small initramfs. This will give us a tiny environment to boot into the device and later install our kernel with.

Ensure that you’ve selected the AR71xx target architecture…

Building an AR71XX System

Next, I opt for the default profile (to give me all the modules I should need)

I demand everything!

And finally, select the build of a ramdisk image:

Fun with arrow keys and a spacebar.

After you’ve made your selections, exit saving your changes, and run make. The build itself will take some time, but when you’re finished you’ll have the first key ingredient – a basic root filesystem embedded into the kernel. This image is essentially a “Live CD” that we’ll use to install our real kernel.

As with all of the images you create, you’ll find them under ~/svn/backfire/bin/ar71xx/ Our newly created image is openwrt-ar71xx-vmlinux-initramfs.elf

Next, we’ll want to build our actual system. To do this, re-run make menuconfig and select the packages that you wish to compile and include in your firmware image. After you’ve made all of your selections, change your Target Image to squashfs and exit saving your changes.

Planting a SquashFS Garden

A quick make later, and we now have a working rootfs and kernel – in addition to our initramfs to install the system with:

openwrt-ar71xx-vmlinux-initramfs.elf (Our temporary kernel)
openwrt-ar71xx-vmlinux.elf (The kernel)
openwrt-ar71xx-root.squashfs (Our Root Filesystem)

We now have almost everything we need.

Oh, the sticker says "Warranty Void if Removed"...

To install our kernel, we need a few additional tools. First off, we need to configure a DHCP server (I’m using ISC’s). Here’s an example from my dhcpd.conf file:

ddns-update-style interim;
subnet netmask {
option subnet-mask;
option routers;

host routerboard
hardware ethernet 00:0c:xx:xx:xx:xx;


Next, we’ll need a TFTP server. I prefer atftpd. No configuration is necessary, simply create a directory to serve files from and start the server:

mkdir /tftpboot/

chmod 777 /tftpboot/

atftpd ––daemon /tftpboot/

The only file that has to be loaded via TFTP is the initramfs kernel. Copy it to /tftpboot with the filename vmlinux and we’re ready to start.

cp ~/svn/backfire/bin/ar71xx/openwrt-ar71xx-vmlinux-initramfs.elf  /tftpboot/vmlinux

Power up the RouterBoard and quickly press the space bar. Select “boot over Ethernet” and it will download and boot the linux kernel.

Opting to boot via TFTP

Next ,we need to install the kernel and root filesystem. Here’s where I ran into my first problem – the kernel has no init variable specified so it panics. Thankfully it clearly states this: “Kernel panic – not syncing: No init found.  Try passing init= option to kernel.

Gratitous Image of a Kernel Panic

Unfortunately the boot loader doesn’t appear to allow one to specify command line options for the kernel and I was unable to find a way to set this when configuring the kernel. (I vaguely recall seeing it when compiling for x86, but may be mistaken). Either way, the solution is simple:

Add your kernel parameters to a file (kernel-params in my instance) and use objcopy to insert it into the ELF file:

The options I used are:

root=/dev/mtdblock2 rootfstype=squashfs,yaffs,jffs2 noinitrd console=ttyS0,115200 init=/etc/preinit

The toolchain supplied with OpenWRT contains a MIPs compatible version of objcopy that will allow you to add a kernel parameters section to the ELF file:

cd ~/svn/bin/ar71xx/

~/svn/backfire/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc- ––add-section kernparm=kernel-params openwrt-ar71xx-vmlinux.elf

To install the kernel, configure an IP on your ethernet  (or bridge) interface, mount /dev/mtdblock1 and use scp to copy your kernel to the device (as “kernel”).

ifconfig br-lan

mkdir /mnt/boot

mount /dev/mtdblock1 /mnt/boot

cd /mnt/boot/

scp kernel


Next, install your squashfs root filesystem to /dev/mtdblock2. Unlike the kernel, This shouldn’t be mounted when installed.

cd /tmp/

scp .

cat openwrt-ar71xx-root.squashfs > /dev/mtdblock2

After the root filesystem is installed, reboot the device and welcome to OpenWRT on the RouterBoard 493AH

It's Alive!

I’m not quite sure what I’ll end up doing with the 493AH just yet. The neighborhood wireless system now consists of 2 Engenius EOC2610 units running firmware images based off OpenWRT… so there may be the potential to add it to the fray.  The 9 ethernet ports would make it ideal for a Quagga router (although I already have one). Installing the MikroTik RouterOS and working with MPLS is another options. Right now it sits on my desk at work as a “pretty cool paperweight with a lot of potential”.

If you have any suggestions – please let me know.