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.

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://svn.openwrt.org/openwrt/branches/backfire 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:

authoritative;
ddns-update-style interim;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.20 192.168.1.40;
option subnet-mask 255.255.255.0;
option routers 192.168.1.1;
}

host routerboard
{
hardware ethernet 00:0c:xx:xx:xx:xx;
fixed-address 192.168.1.17;
}

 

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-0.9.30.1/binutils-2.19.1/binutils/objcopy ––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 192.168.1.10

mkdir /mnt/boot

mount /dev/mtdblock1 /mnt/boot

cd /mnt/boot/

scp 192.168.1.1:~/svn/backfire/bin/ar71xx/openwrt-ar71xx-vmlinux.elf kernel

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

cd /tmp/

scp 192.168.1.1:~/svn/backfire/bin/ar71xx/openwrt-ar71xx-root.squashfs .

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.

I’m looking forward to the upcoming CPLUG presentation: “Unleash your home router’s potential“. As 48 users will now attest, the captive portal I’ve been building has been a pretty big success.

Numerous attempts to fix the EOC-2610 reboot bug have all been in vain. The problem is this: the device reboots fine until the wireless modules are inserted AND the device placed into Master mode (to serve as an access-point). Removing the modules, using GPIO pin 0 instead of 5 to reset, pointing things back to the bootloader at either address 0xbfc00000 or 0xa8000000, and numerous other tests all fail. I cannot seem to locate the source that Engenius uses (which would help in finding the solution), and neither Engenius nor Senao will respond back to emails or Facebook posts. (I’ve spoken to Engenius reps in California that have pointed me to Singapore – I’ve been on hold for almost an hour there to no avail).

Serial Connection or Brain Surgery. Can't see it well enough to say.

But enough complaining, I’ll fix that bug eventually.

Update 8/10/2010: A coworker suggested double-checking voltage and direction on GPIO pin 0, as well as ensuring that AR2315_RESET_GPIO was set correctly this morning. Sure enough, I had a problem. I’ll release a very basic patch shortly. -=Bug squashed=-

Here’s the lowdown on how to build a basic linux kernel and rootfilesystem using OpenWRT and how to install your new firmware via the Redboot bootloader. I’m posting it as a quick introduction.

First off, use subversion to grab the appropriate source. In this instance, I’m using the BackFire port:

svn co svn://svn.openwrt.org/openwrt/branches/backfire

This contains everything you need to get started: toolchain, compiler,  and scripts to pull in the source for the kernel and all packages that will be built. OpenWRT is very well documented, and it’s worth the time to read the README file as well to build and read the contents of the docs/ directory.

Menuconfig is used to determine not only kernel options, but packages that will be built as part of the firmware image.

cd backfire
make menuconfig

Obviously the first thing you want to do is set the appropriate Target System. For the Engenius EOC-2610, you’ll want to use Atheros AR2315:

Menuconfig: Selecting your Target

Next, ensure you select squashfs for the Root filesystem image (under Target Image). Target Profile will only have one option (Default), so no changes are needed there. I generally use the default Global build settings (as they’re ample), but look them over if you want more advanced debugging options and to enable things like IPv6, etc.

The Image Builder option is to allow creation of a firmware image using precompiled binaries. I generally leave this and the other Main build options off..

Base system is exactly as it sounds: it’s a list of base utilities like dropbear, bridging utilities, iptables, mtd, and other items. In fact, all of the remaining options are fairly self-explanatory: Network, Libraries, Kernel Modules – they all mean what they say. If you can’t find an option, use “/” and search for it. Luckily a working firmware (that incorporates wireless) can be built with simply selecting the correct target (Atheros AR2315). You can add more features later.

When you’re ready to roll, a simple make V=99 will cause the OpenWRT system to download all the appropriate tools, compile them, and build your firmware. Obviously the first time you build an image, it will take some time. Subsequent builds focus solely on the kernel and root filesystem, not building the entire toolchain. The images are found under the bin/ directory.

For Future Reference: The Serial Pinouts

Now that you have an image, one has to use the Redboot bootloader to upload it. There’s excellent documentation out there on this as well, but here’s a quick rundown:

Use a crossover cable to connect to the Engenius EOC2610′s Ethernet port. The bootloader defaults to using 192.168.1.1, so configure your IP accordingly (for this example, I’m using 192.168.1.2).

In one terminal, start pinging 192.168.1.1. Plug in the PoE adapter to start the 2610 and upon receiving an ICMP response, telnet to 192.168.1.1, port 9000. (Since you need to send a Ctrl-C to the Redboot bootloader, I have found that using puttytel seems to be the preferred method to connect to it). You may find a blank screen that doesn’t respond – if you do quickly disconnect and reconnect to the device.

The first time you'll lay eyes on Redboot.

When you see the above screen (and have hit Ctrl-C), you’re ready to go.

Ensure that you have a TFTP server on your local machine and that the kernel (openwrt-atheros-vmlinux.lzma) and rootfs (openwrt-atheros-root.squashfs) are in the TFTP root location. Next, configure the bootloader to use your system as a TFTP server (and ensure that it can connect to you):

RedBoot>
RedBoot> ip_address -l 192.168.1.1 -h 192.168.1.2
IP: 192.168.1.1/255.255.255.0, Gateway: 0.0.0.0
Default server: 192.168.1.2
RedBoot> ping -h 192.168.1.2
Network PING – from 192.168.1.1 to 192.168.1.2
PING – received 10 of 10 expected
RedBoot>

Uploading the kernel is easy:

RedBoot> load -r -v -b %{FREEMEMLO} openwrt-atheros-vmlinux.lzma -m tftp
Raw file loaded 0×80041000-0x80110fff, assumed entry at 0×80041000
RedBoot>

Ensure that everything was uploaded ok and that the checksums match:

RedBoot>
RedBoot> cksum
Computing cksum for area 0×80041000-0×80111000
POSIX cksum = 472679704 851968 (0x1c2c8518 0x000d0000)
RedBoot>

me@vonnegut/tftpboot $ cksum openwrt-atheros-vmlinux.lzma
472679704 851968 openwrt-atheros-vmlinux.lzma

If all is well, format the flash and burn the kernel image:

RedBoot> fis init
About to initialize [format] FLASH image system – continue (y/n)? y
*** Initialize FLASH Image System
… Erase from 0xa87e0000-0xa87f0000: .
… Program from 0x80ff0000-0×81000000 at 0xa87e0000:

RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0xA8000000  0xA8000000  0×00030000  0×00000000
FIS directory     0xA87E0000  0xA87E0000  0x0000F000  0×00000000
RedBoot config    0xA87EF000  0xA87EF000  0×00001000  0×00000000
RedBoot> fis create -r 0×80041000 -e 0×80041000 vmlinux.bin.l7
… Erase from 0xa8030000-0xa8100000: ………….
… Program from 0×80041000-0×80111000 at 0xa8030000: ………….
… Erase from 0xa87e0000-0xa87f0000: .
… Program from 0x80ff0000-0×81000000 at 0xa87e0000: .
RedBoot>

You can then verify that the kernel is saved to flash:

RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0xA8000000  0xA8000000  0×00030000  0×00000000
vmlinux.bin.l7    0xA8030000  0×80041000  0x000D0000  0×80041000
FIS directory     0xA87E0000  0xA87E0000  0x0000F000  0×00000000
RedBoot config    0xA87EF000  0xA87EF000  0×00001000  0×00000000
RedBoot>

Excellent – it is. Next up – the rootfilesystem. It’s loaded into memory via the TFTP  server in the same fashion as the kernel (again, run a checksum to ensure all transferred fine):

RedBoot> load -r -v -b %{FREEMEMLO} openwrt-atheros-root.squashfs -m tftp
Raw file loaded 0×80041000-0x801a0fff, assumed entry at 0×80041000
RedBoot>

RedBoot> cksum
Computing cksum for area 0×80041000-0x801a1000
POSIX cksum = 3009821226 1441792 (0xb3663a2a 0×00160000)
RedBoot>

me@vonnegut/tftpboot $ cksum openwrt-atheros-root.squashfs
3009821226 1441792 openwrt-atheros-root.squashfs

Next, determine how much space is actually free in FLASH. It helps to use bc to calculate this:

RedBoot> fis free
0xA8100000 .. 0xA87E0000
RedBoot>

bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty’.
iscale=16
oscale=16
A87E0000-A8100000
690000

With this information at hand, you can burn in the Root Filesystem, utilizing all the free space:

RedBoot> fis create -l 0x690000 rootfs
… Erase from 0xa8100000-0xa8790000: ……………………………………………………………………………………………
… Program from 0×80041000-0x801a1000 at 0xa8100000: ………………….
… Erase from 0xa87e0000-0xa87f0000: .
… Program from 0x80ff0000-0×81000000 at 0xa87e0000: .
RedBoot>

That’s it – you’ve now uploaded your firmware to the device. Next, lets just double-check and ensure all is well, and finally – let’s boot our new image:

RedBoot>
RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0xA8000000  0xA8000000  0×00030000  0×00000000
vmlinux.bin.l7    0xA8030000  0×80041000  0x000D0000  0×80041000
rootfs            0xA8100000  0×80041000  0×00690000  0×80041000
FIS directory     0xA87E0000  0xA87E0000  0x0000F000  0×00000000
RedBoot config    0xA87EF000  0xA87EF000  0×00001000  0×00000000
RedBoot>
RedBoot> fis load -l vmlinux.bin.l7
Image loaded from 0×80041000-0x802a0200
RedBoot> exec

At this point, detach from the telnet session (no output will be seen when the device boots), and once the system has booted – connect using telnet (or SSH if compiled).

The OpenWRT Busybox shell

Next up – customize your firmware image and build your own packages  – and check out the upcoming CPLUG meeting on unleashing your home routers potential.

I’ve really been enjoying the feedback on the free wireless access from my neighbors. As always, everytime I start a new hobby, I end up with a handful of new toys – and I got one just today:

The Wi-Spy 2.4x

The Wi-Spy 2.4x is a portable USB spectrum analyzer for the 2.4Ghz range (They have other models that cover 900mhz and 2.4/5Ghz). The 2.4x model includes an external antenna (SMA), whereas the 2.4i has an internal antenna only.

The Accompanying Chanalyzer software

With the use of a wireless card, one can overlay SSID’s atop the channels in the Topographical  graph and determine what radiation  belongs to which Access Point. The bottom graph (Planar view) allows one to view which Zigbee channel, wifi channel, or frequency range is most in use.

There’s a similar device on the market which is substantially cheaper, the Airview,  manufactured by Ubiquiti Networks (~$39 vs. ~$160), but from what I’ve seen, the Chanalyzer sofware in use with the Wi-Spy appears to have more features (the ability to record your captures, the ability to overlay RF “fingerprints” of various devices atop your captures), etc. The Airview software is written in Java (Read:  supported in Linux), whereas Chanalyzer is written in .NET (good luck with that one under WINE).

There are Linux tools for use with the Wi-Spy (Spectrum-Tools) which I can defnitely appreciate,  but again the recording/playback and fingerprinting along with SSID overlays really make Chanalyzer nice. (For the record, you can actually record the data using one of the tools in the Spectrum Tools suite… I don’t believe you can playback easily though)

Spectrum Tools: from the author of Kismet

I’m supposed to be working on a number of other things at the moment (studying for an exam being the major item on my to-do list) so unfortunately this post is more of a “guess what I just got” as opposed to a “look at what this can do”.  In the next few weeks, I plan on picking up an AirView also, and will provide a side-by-side comparison of the two.

In the meantime, check out this video advertising the Wi-Spy, and if you have any experience, recommendations or thoughts on it or the AirView – hit me up in the comments.

I’ve done quite a bit in the past few months with the neighborhood wireless project.

First off, I’ve moved everything from the Linksys WRT-54GTM devices to an Engenius EOC-2610. The system Atheros AR2315 based. (More pictures here)

An Engenious Naked. Totally hot.

The firmware is still OpenWRT kamikazee (I dumped DD-WRT a while ago on the 54G’s), with a patched version of the NoDogSplash captive portal  (to prevent the graceful exit when a null token is submitted, also to support a “Magic token”, since I don’t truly care about it being the same one issued during the pre-authentication phase).

The only lingering issue relates to my version of the hardware not handling a reboot, which is a known issue apparently related to the kernel’s watchdog driver. There’s already a patch out there, and I plan on implementing it soon. (At present, an “init 6″ will simply cause the unit to stop responding – requiring an actual powercycling) The good news is that I’ve never had to actually reboot the device for any reason.

Other installed packages include NProbe for Netflow export and  SNMP for monitoring/graphing purposes. In all honesty, the build is rather simple but effective. It’s also waterproof – the Engenius EOC-2610 is built for outdoor use – complete with waterproof housing and PoE support (albeit based on the warnings on the PoE injector, I don’t believe it’s 802.3a[ft] compatible)

As of this morning, we’re up to 13 users in the neighborhood. Shortly, I’ll be lighting up the Eastern portion of the neighborhood, which will provide access to a larger number of users.

Oh, and there’s a new look to the portal:

The new Midtown WiFi Theme

The new look is a slight modification to the Lorea Hub Theme, with additional imagery from istockphoto.com.

For the last 6 months or so, I’ve been running a free wireless access point for my neighborhood. In an effort to get my local community to know each other (and local goings-on), I’ve back-ended the system using the elgg social networking platform.

To use the free wifi, you have to register on the social site.

The Captive Portal

Uptime however has been a major pain – for quite some time NoCatSplash has been broken in DD-WRT. Ever since version 24 (at the very least), it’s been grouchy – all of the sudden not working and requiring a reboot (or possibly clearing and resetting the iptables targets and restarting splashd)  to fix. The wiki documents a few workarounds, but I’ve gotten tired of the overall bugs.

Initially I planned on simply fixing it, but after a little bit of thought,  I decided to give OpenWRT another look. I’m sure I could have gotten away with using the mini or micro versions of DD-WRT and adding to it, but last time I used OpenWRT’s build environment I was really impressed – so I spent this weekend working with it again.

Building your own image is simple – using the ImageBuilder system (I’m working with WRT-54G’s)  simply “make image” setting the target PROFILE and PACKAGES via environment variables. This method uses existing binary packages to build a .bin or .trx file for easy installation (via the web interface or mtd command). “make info” will give you a long list of profiles, and packages that are readily available are contained in the packages subdirectory.

Recompiling packages is extremely easy – download the SDK:

mkdir ~/devel && cd ~/devel

wget http://downloads.openwrt.org/kamikaze/8.09.2/brcm-2.4/OpenWrt-SDK-brcm-2.4-for-Linux-i686.tar.bz2

tar xjvpf OpenWrt-SDK-brcm-2.4-for-Linux-i686.tar.bz2

If the package already exists, check it out via subversion:

cd OpenWrt-SDK-brcm-2.4-for-Linux-i686

svn export svn://svn.openwrt.org/openwrt/packages/net/<packagename>  package/<packagename>

And to compile simply execute:

make package/<packagename>/compile V=99

(On older versions it’s “make package/<packagename>-compile V=99″)

After hitting my head against the nocatsplash package’s failure to build correctly, I finally opted to look at nodogsplash. “Because it will at least build” is probably not the best way to choose captive portal software, but it’s mine.

First thing requiring a fix is a bug that causes nodogsplash to crash when one sends a request to the auth-server without a “redir” GET variable being set – a bug evidenced by:

links “http://192.168.1.1:2050/nodogsplash_auth/?tok=fffffff”

Thankfully the crash is “gracefully” handled in safe.c’s safe_strdup()…. but it still causes the daemon to crash.

So – a quick patch, as well as some added “features” (including a magic token) and I’m set. Patches to source can be added to package/<packagename>/patches. Upon make, patches in this directory are first applied.

So instead of waiting around for a fix to NoCatSplash in DD-WRT, I’m moving on. So far NoDogSplash has proven effective – although I’m far from actually migrating to it (the old access point is still running for the time being). In the next few weeks I should have a custom web interface built, as well as pmacctd configured (I am exporting Netflow version 9 data to a collector as a C.Y.A measure), and bandwidth shaping properly enabled.

Custom patches to NoDogSplash are forthcoming.