Building a wardriving box

I am building a dedicated wardriving box. Which means: a small PC which boots a very minimal Linux and automatically runs Kismet.


I like wardriving, finding new wireless networks announcing themselves and logging high numbers of found networks at WiGLE so I climb in the WiGLE stats.

I currently use a Dell Latitude C640 laptop for wardriving. The interesting part is connecting an external gps and powering it.

Over time, I used several ways of connecting a gps. The first option was the gps-usb cable. But the usb connection got interrupted on bumps which happen a lot when bicycling. When the usb connection gets interrupted the Linux usbserial driver closes the serial connection and gpsd does not reopen that connection automatically. I had weird scripts which would restart gpsd and cycle kismet.

The second option for powering a gps was a serial + keyboard connector cable. This worked for a long time until the keyboard connector broke off.

The third option was keeping the serial connection for data and fixing a cable which gets power from the usb port. This worked for a time until the usb port started coming loose from the mainboard of the laptop. Now it is flaky and sometimes most or all of a wardrive is without gps locations.

Only new networks with gps locations count at WiGLE, so I want a working gps. I could get a new laptop, but maybe I could build a dedicated box which would only do wardriving. That would also be easier to bring on car trips with my wife, she is not always charmed by me spending ten minutes in the car starting kismet and setting up the wardrive equipment before we can drive off. A box with a 'go' button which I can put in the car would work better.


For project sundial, a self-powered weather station and gps time server, I came across a very low-power PC board: The PC Engines Alix.1C. I think this board has enough CPU power to run kismet. This is a mini-ITX board which is a standard form-factor that I can find cases for. Suddenly I had the idea (ok, a co-worker said to me a while ago "why bother with a laptop which you demolish, why not go with a small itx board) that this could also solve the wardriving hardware problems and get me the ideal wardriving box that I can take by bike and by car.

LinITX sells the PC Engines Alix.1C. When I asked them what enclosure would fit LinITX suggested the Mini-box M200 enclosure (product page at Mini-box) Mini-box M200 Enclosure (page at, review at Mini-box M200 Enclosure review or the Mini-box M300 Enclosure for a bit more space internally. Mini-box M300 Enclosure review.

If I read the specs of the enclosure and the mainboard correctly I need to buy a 10 cm 44pin ide cable to connect the frontpanel CF reader to the internal 44 pin ide bus. LinITX link: 10 cm 44pin ide cable. I won't have to open the case to change the compact flash.
Well, the specs missed the fact that the M200 case has a normal 40 pin ide connector. Hope a 40 to 44 pin ide cable can solve this.

Also, a wireless card, the Wistron CM-9. LinITX link: Wistron CM-9 minipci 802.11abg adapter. This card has the atheros chipset for madwifi now and ath5k later with 2 u.fl connectors so I can add a female N connector and a reverse sma connector to the case with a small rubberduck type antenna for the reverse sma connector. And the N connector for the big wardriving antenna.

And a gps receiver connected to the serial port. I use the Rikaline GPS 6010-X5 I already had for wardriving.


Easiest seems to be to get a simple rechargable battery at 12V which can be hooked up to the mini-itx case. With some serious protection against shorting of the power terminals. I considered building the batteries into the case but that would make stuff a lot more complicated.

I ordered a lightweight battery (12V, 2.2 Ah, 700 grams) from Conrad with a charger. It should enable me to cycle (or drive) for at least two hours which is the usual time I stay interested in wardriving.

The whole box uses 420 mA in normal use. In theory, that would give over 5 hours of battery time. In practice the voltage will drop eventually and the power controller of the alix will cut it off. I measured 4 hours 39 minutes of active time.


A very minimalist Linux, running from ramdisk, with enough drivers to get kismet running to console.
Fortunately, I'm not the first one considering running linux from compactflash. Virtu did the heavy lifting on this matter already and Remco van Mook has put some samples on-line.
What I will need is: a development environment on a 'big' PC with sources (kernel, drivers, kismet, other software) in one dir. Where files that will be in the resulting filesystem in ramdisk will be gathered in a second dir. With kernel, bootloader and gzipped filesystem image of that resulting filesystem in a third directory ready to be copied to compact flash.
Things that I want to run:


Linux, wireless driver, network driver. Minimal daemons. Boot from CF. Maybe running from ramdisk. Enough ACPI driver so it can detect a powerdown request.

Wireless network

Running kismet on the console, automatically starting at boot. Maybe accepting kismet UI connections over the wired network. Saving logs to CF on shutdown. Maybe saving logs to CF on a regular basis. I set the kismet logging path directly to CF.

Wired network

Probably with ifplugd on the ethernet network with some scripts so the box automatically acquires an IPv4/IPv6 address and transfers the wardriving logs to safe storage on the home server.


Sound? Yes, I want to use a minimal bit of sound, to signal the state of the system. State changes such as 'starting wardriving mode', 'stopping wardriving mode' and 'starting copying files to server' need a sound so I know what is happening and I have a slight idea whether things work as planned without hooking up a monitor.

The Alix.1c does have audio inputs and outputs, but I'm going to use something simple: the built-in PC speaker. To control that, I use the program aptly named beep which does just that: play tones from the PC speaker at a given frequency, duration and repeat.


On a workstation I created a new minimal debian install in /root/ritchie-install using
~# debootstrap etch /root/ritchie-install
After that I dug into it with
~# chroot /root/ritchie-install
and started throwing out packages again.
Installing kernel modules to the build tree:
src/linux- INSTALL_MOD_PATH=/root/ritchie-install make modules_install
Compiling madwifi:
src/madwifi-0.9.1$ make KERNELPATH=/home/koos/project/wardriverbox/src/linux-

Install madwifi to the build tree:

src/madwifi-0.9.1# make install-modules KERNELPATH=/home/koos/project/wardriverbox/src/linux- \

Do a module dependency check with the right paths:

src/linux- depmod -b /root/ritchie-install/ -ae \
-F ~koos/project/wardriverbox/src/linux-

I installed the CF as one partition with ext3 filesystem: eventually wardriving logs will be saved to that partition so it needs all the robustness it can get.

Building version 2

The second box uses /home/root/dabox-install and a linux kernel which means the ath5k kernel driver is more usable than madwifi. Installing kernel modules to the build tree:
src/linux- INSTALL_MOD_PATH=/home/root/dabox-install make modules_install
src/linux- chroot /home/root/dabox-install depmod -ae

Installing grub on the CF card

Installing grub 1 using the development system

This worked when the development system was a debian install where grub 1 was the normal bootloader.

Grub:Installing GNU/Linux on a CompactFlash Card Mini-HOWTO and fc6 grub menu.lst won't load had the right incantations for grub. In the development system the CF card ends up as /dev/sdc which is enumerated by grub as hd3 so the right sequence for a system with 'native' grub is:
$ grub
grub> root (hd3,0)
grub> setup (hd3)

Installing grub 1 as grub-legacy in the development chroot

To create an environment for grub-legacy that without changing anything within my running install, I used debootstrap again:
~# debootstrap etch /home/root/tempforgrub
And within that environment, installed grub-legacy:
root@jobs:~# chroot /home/root/tempforgrub
root@jobs:/# apt-get install grub-legacy
Grub needs access to the disk devices. I made really really sure the CF was /dev/sdc ..
root@jobs:/# mknod /dev/sdc b 8 32
root@jobs:/# mknod /dev/sdc1 b 8 33
Now grub can be installed. There are (in the chrooted environment) no other disk devices visible, so in this case the target disk is (hd0).
root@jobs:/# grub-install --root-directory=/mnt '(hd0)'

Installing grub2 via pxebooted PLD linux

PXEbooting PLD linux on the alix.1d is also an option, which gives grub2 within the booted environment. The CF is in this environment device /dev/sda with one big /dev/sda1 partition.
# mkdir /mnt
# mount /dev/sda1 /mnt
# grub2-install '(hd0)' --root-directory=/mnt

Menu for grub version 1

timeout 5

default 0

fallback 1

title Wardriver
kernel (hd0,0)/linux- root=/dev/ram0 ramdisk_size=55296
initrd (hd0,0)/rootimg.gz

title Wardriver Default
kernel (hd0,0)/linux- root=/dev/ram0 ramdisk_size=55296 defaults
initrd (hd0,0)/rootimg.gz

Config for grub version 2

set root=(hd0,1)
linux (hd0,1)/linux- root=/dev/ram0 ramdisk_size=55296
initrd (hd0,1)/rootimg.gz

Copying the chrooted install to the rootimg

Copying stuff to the compact-flash card goes in two stages:

The rootimg is a file created as a 64 Mib filesystem. Commands:
cfimage$ dd if=/dev/zero of=rootimg bs=1024k count=64
cfimage$ mke2fs -j rootimg
mke2fs nags a bit about the rootimg being a file and not a device.

Copying files goes with a script which avoids copying anything to the rootimg which isn't really needed there. The whole debian adminstration is only needed on the local installation, not on the CF. The rootimg is stored compressed on the compact flash and on the local staging directory which means it has to be decompressed before any changed and compressed.



if [ -f $FSIMAGE.gz ]; then
        echo -n "Decompressing image ... "
        gzip -d $FSIMAGE.gz
        echo "done."

if [ ! -f $FSIMAGE ]; then
        echo "No root image"

mount -o loop $FSIMAGE $MNTPT || exit 1

rsync -avHS --progress --delete --delete-excluded --exclude=usr/share/zoneinfo --exclude=usr/share/i18n --exclude=var/lib/dpkg --exclude=var/cache --exclude=usr/share/apt --exclude=usr/share/aptitude --exclude=usr/share/locale --exclude=var/lib/apt --exclude=/root/.bash_history --exclude=var/log/dpkg.log $SOURCE/ $MNTPT/


umount $MNTPT

# yes, I actually wrote to that file ..

touch $FSIMAGE

echo -n "Compressing image ... "

gzip -9 $FSIMAGE

echo "done."

Other stuff in the local staging directory for the compact flash is the linux kernel and the grub boot files.
cfimage$ ls -l
total 18636
drwxr-xr-x 3 root root      4096 Jan 24 22:19 boot/
-rw-r--r-- 1 koos users   787919 Jan 26 20:38 linux-2.4.36
-rw-r--r-- 1 koos users 18259594 Jan 25 23:09 rootimg.gz
To save to compact flash, a second script does the work:


modprobe usb-storage

mount $FLASHPART $MNTPT || exit

rsync -avHS --progress --delete $SOURCEDIR/ $MNTPT/

umount $MNTPT

echo "Done syncing"

rmmod usb-storage


As planned, the box works headless. In normal running there are two inputs: the power button and the wired network interface. The system will boot up on a power button push (normal itx behaviour). When startup is complete and the wardriving script starts (from inittab) it will play a sound via the speaker. When the system is running and the power button is pressed shortly an acpi event is posted. The handler for this event is the shutdown script. The shutdown script takes over, shuts down kismet which saves the collected logs to flash and the system powers down. On connection to wired network ipv4 and ipv6 addresses will be acquired, kismet will be stopped (saving results to flash) and the results rsynced over ssh to the home server (reachable via both ipv4 and ipv6). The public key of the wardriving box only has access to one account and can only upload files via rsync, not download or delete them or do anything else with a shell.


Yes! Lots of them. Thousands of new networks have been found. And it is a lot easier to bring the wardriving box on a car ride when I dont have to deal with weird commands to get the wardriving setup running. The box has two inputs, a power button (for startup and shutdown) and a network adapter. Wardriving starts at powerup and stops when the power button is pressed or network link is detected. At network link the results files will be copied to the server at home.


Set wardriving box at flickr img_5860

Similar projects

I'm not the only one doing (or thinking about doing) this: A 'car' wardriver could use one of the automatic 12V powersupplies to automatically start and stop the wardriving. Even nicer when other people drive the car and you still want those drives logged. Just be sure to tell the driver what the software running in the car is capable of: logging their tracks.

Building your own?

Trying to duplicate this effort means you must me really good with Linux, not afraid to compile your own hand-tuned kernels and have an already available system running a unix with sshd to copy the results to.
This page originally lives at

Comments about this page and updates are welcome. E-mail is the preferred contact method.
Koos van den Hout (
Other webprojects: Camp Wireless, wireless Internet access at campsites