First step is generic for all platforms and that is to get the OpenWRT development environment (herin refered to as 'Backfire')
The instructions are available at the OpenWRT development site at https://dev.openwrt.org/wiki/GetSource and that site should be assumed to be the source of truth but I will summarize here
Get the source, remembering that you will eventually need around 3-6 Gb of space once everything is built, so make sure you have enough there.
svn co svn://svn.openwrt.org/openwrt/branches/backfire
This will download the backfire source and build environment to build your own firmware with the Kismet Drone built in.
NOTE: Should you want to use a pre-built binary for your platform, feel free, however in some cases this will cause problems as they won't have enough free space for the drone binaries unless they are built into the image. In addition, you will need to have the build environment anyways if you want to build an up to date Kismet Newcore drone binary, so might as well build it anyways.
Once you have the source and build environment downloaded, go into the directory and run 'make menuconfig'
cd backfire
make menuconfig
This will build and run the firmware build configuration utility. From there, don't change anything except the target system. Change it to your targets profile:
WRT54GL:
System: Broadcom BCM947xx/953xx
Profile: Broadcom BCM43xx WiFi (Default)
Ubiquiti Routerboard:
System: Atheros AR71xx/AR7240/AR913x
Profile: Ubiquiti Routerstation
Accton 3201A:
System: Atheros AR231x/AR5312
Profile: Default
Once you've selected your target profile, select exit, save your changes and then exit.
Note: The next step is to download the additional packages, but it sometimes fails horribly unless you do a make menuconfig first.
Backfire has a Kismet Newcore package built, but it is uaually out of date and it is recommended to use the newest version possible so as to get bug fixes, etc. For this reason, you will want to build your own to follow release versions or if you are really adventurous, SVN. The Makefile that is in the source only needs some minor tweaks to build the software with the latest version.
To add the package to the build environment, you just run a simple SVN command
make package/symlinks
This will download the Makefiles for the extended packages into the build environment. The next time you run 'make menuconfig', the new packages should hopefully be available in the menu to enable for building.
If you want to confirm that it worked successfully, just run 'make menuconfig' and you should see a bunch more packages available to build.
Since the Makefile included with the build environment pulls a very early version of Kismet Newcore to build, it needs to tweaks to use the newer and more mature code.
There are two ways to go about this. One is to use the latest release version (available on the Kismet site with the format kismet-YEAR-month-release number), the other is to grab a snapshot of the SVN version and use that. It all depends on your needs and ability to deal with ever changing code.
Release version:
If you want to follow a release version, you won't be running the latest code from SVN which may fix any problems you encounter with the drone, however you will have some assurance that the code will work and not break suddenly.
In your backfire directory, edit the kismet Makefile which sits in feeds/packages/net/kismet/
We only need to edit some of the first lines in the file:
PKG_VERSION:=20010-01-R1
This needs to be changed to the latest release version on the Kismet site, which at the time of writing is Kismet-2010-07-R1
PKG_VERSION:=2010-07-R1
The Makefile already knows where to download the Kismet source, we are just adjusting the filename variable so we get the latest release source.
If you want to assure the integrity of your source tarball, you can edit the "PKG_MD5SUM:=" line to reflect the MD5 of the release package. If you don't want to use that, you can simply remove this line and the tarballs checksum will not be checked.
PKG_MD5SUM:=
SVN version:
If you want to follow SVN, you will have the latest code and the latest bug fixes, however since it's 'live', it's possible for something to get horribly broken at any time. Also, this presents a problem of an ever moving target and of things changing too rapidly to track where any problems may be coming from. Because of this, I suggest and will show how to make a snapshot of SVN that changes only when you download and load a new tarball into the build system.
To start, you need to download SVN of the Kismet Newcore source:
svn co https://www.kismetwireless.net/code/svn/trunk kismet-devel
This will download the Kismet Newcore source into the kismet-devel directory. From there we will make a tarball of the source and use that:
tar czvf kismet-devel.tar.gz kismet-devel/
After we have made the tarball we need to make changes to the Makefile in your backfire directory. Edit the kismet Makefile which sits in feeds/packages/net/kismet/
We only need to edit some of the first lines in the file:
PKG_VERSION:=2009-06-R1
This needs to be changed to use our SVN tarball that we made
PKG_VERSION:=devel
If you want to assure the integrity of your source tarball, you can edit the "PKG_MD5SUM:=" line to reflect the MD5 of the SVN tarball we made earlier
PKG_MD5SUM:=
Now, you'd think that the Makefile will want to download the kismet-devel.tar.gz from the Kismet website, but that is where we get tricky on the system. The build environment, when it builds the system will download and unpack the source for everything it builds. Now if you make changes and do the build again, the system is smart enough to check if it already has the source downloaded. Once we have made the tarball, we have to put it somewhere to trick the system into using that source instead of trying to download from the Kismet site. Simply copy the kismet-devel.tar.gz file into the download directory (dl/) in your backfire source directory (NOTE: The DL directory is created when you start a 'make' and may not be there if you have'nt run 'make' yet).
Assuming your root is called 'backfire':
cp kismet-devel.tar.gz backfire/dl
The system will now see the kismet-devel.tar.gz package in the dl/ directory and use that. This prevents the system from going out to the web to try and download the file, and also gives you the ability to change out the source at the time of your choosing.
Once you have the Makefile adjusted and if nessecary, the source files in place, you can now run 'make menuconfig' again and select the kismet-drone package to build.
make menuconfig
Network -> Wireless -> kismet-drone
If you want to make a seperate module you can load with opkg, when you select the kismet-drone package, select it where it says "M". If you want to build the drone binaries into the firmware image (recommended for WRT54G's and any platforms with limited memory or for large productions) then make sure it is selected with a star "*" instead.
Once you have enabled the kismet-drone package, exit and save your configuration. Once you exit, start the build process make download world Once the build starts, it will download all the source for the packages it needs and the start compiling
everything. This can take a very long time depending on your system, so go have a beer or seven as this can take
hours, especially on the first run.
Step Six
If the build process completes sucessfully with no errors, you can move onto loading your router with the OpenWRT software. Depending on your platform, this can vary, but the OpenWRT site has instructions for most platforms. They are the source of truth, so check them out for your particular platform.
The custom firmware you built is stored in the achitecture name under the "bin" directory in your build directory. This is especially important if you built the kismet-drone into the firmware as you should use that instead of a version off the OpenWRT site.
cd bin/
The OpenWRT site wiki has instructions for most platforms, however one that seems to be missing is the Accton MR3201A, the basis for the FON 2200 router and the OpenMesh OMP1 low cost router, so I'll add it here.
To install on the Accton router, it's not a simple tftp like most platforms. The easiest way is to use the Open-mesh flashing utility. Head on to the Open Mesh development site and download the open-mesh-flash utility (there is a windows version too). With this, you can upload the kernel and root fs to the router, which are the files ending in "root.squashfs" and "vmlinux.lzma". You will need to configure the wired network interface on your system to the 192.168.1.0/24 subnet, anything except 192.168.1.1. When you run the open-mesh-flash utility and specify the interface your router is connected to along with the root and FS files, the program will connect and upload the new firmware.
./open-mesh-flash eth0 openwrt-atheros-root.squashfs openwrt-atheros-vmlinux.lzma
Once this runs, and the firmware is uploaded, you can continue on
If you chose to build a package, you can find it in your build directory under the "bin/Architecture/packages" directory. Copy it to your router with SCP:
scp kismet-drone
and install it with opkg
opkg install kismet-drone
Once you have the Kismet Drone package on the system, however you chose to do it, it's time to configure it. Depending on your platform, configuration is pretty much the same few things.
After telnetting to your drone and setting and SSH password, SSH back in and you can edit the system to get monitor mode.
Assuming you are using this unit as a dedicated drone, you will want to enable and setup the wireless interface(s) to monitor mode at boot up.
To enable the wireless cards on your router, edit the /etc/config/wireless file and enable the radio(s)
# REMOVE THIS LINE TO ENABLE WIFI:
option disabled 1
This should be changed to:
# REMOVE THIS LINE TO ENABLE WIFI:
option disabled 0
You can also remove the line or just comment it out.
When you are editing the /etc/config/wireless file, you should also set the interface to be in monitor mode on bootup. To do this, change the following:
option mode ap
This should change to:
option mode monitor
In addition you can delete or comment out the following two lines since they are not needed:
option ssid and option encryption
Now that the radio(s) are enabled and set to monitor mode, time to configure the Kismet Drone. All options are set in the /etc/kismet/kismet_drone.conf file changing the following lines at a minimum.
dronelisten=tcp://
This line sets what IP address/interface the drone will communicate with the server over. If you have multiple interfaces and/or static IP addresses, you can specify the IP you want to listen for commands from the server on. If you use DHCP (you won't know what address you will get) or you have multiple interfaces you want to listen on, you can list several IP's comma seperated, or use the address 0.0.0.0 which will listen on all available interfaces.
The next line sets which IP addresses can connect to the drone:
droneallowedhosts=127.0.0.1
If your server is not on the drone itself, you will need to add something here. Multiple addresses can be specified, comma seperated. Using the address of 0.0.0.0 will allow *any* IP address to connect.
NOTE: Using 0.0.0.0 allows anyone to connect, there is no authentication beyond that. If this drone is connected to a public IP, anyone can connect and listen to the traffic. This is probobly not a desireable situation as anyone on the internet can sniff wireless traffic that you may not want them to!
Depending on your drone, you may or may not have a GPS.
If you have a GPS, leave it as true and set your other options:
gps=true
If you don't, to cut down error messages, disable it with:
gps=false
Last and most manditory, you will need to set the source line. The good news is that as long as you did'nt select the "Broadcom BCM947xx/953xx [2.4]" target system, you can get away easy. If you did select a 2.4 branch, read the Kismet README, section 7 and figure it out on your own and let me know.
If you picked any of the 2.6 kernel targets, you can generally get away with the following as your source:
ncsource=wlan0
NOTE: Later versions of OpenWRT's MAC80211 driver use 'ath0' as the interface name. If you are getting errors about non-existant interfaces, try using 'ath0'
There are many other options in the Kismet_drone.conf file that you can setup. Most are well commented and self explainitory.
Once you have the Kismet Drone configured, you can fire it up to test from the command line by typing:
kismet_drone
If all is well, no major errors should show in the output and the last line should be something like the following, but with your interface name:
INFO: Started source 'wlan0'
In order to start the Kismet Drone on startup, you will need to add a startup script. This is actually very easy to do, simply copy the following into a new file called /etc/init.d/kismet-drone:
#!/bin/sh /etc/rc.common
# Kismet Drone Startup Script
# Copyright (C) 2007 OpenWrt.org + RenderLab.net
START=70
STOP=15
boot() {
echo boot
# commands to run at boot
# continue with the start() section
start
}
start() {
echo start
# commands to launch application
kismet_drone
}
stop() {
echo stop
# commands to kill application
killall kismet_drone
}
Once you copy the script into a file, save it, then make it executable:
chmod a+x /etc/init.d/kismet-drone
Then enable the script so it creates the realivant start and stop links in the /etc/rc.d directory:
/etc/init.d/kismet-drone enable
And with that you can restart the router and if everything is as it should be, the drone will start automatically.
Now that you have a Kismet Drone running, time to now connect a Kismet server. The line you need to now is:
drone:host=
In addition to the client GUI, you can start Kismet with a drone from the command line with pretty much the same line:
kismet -c drone:host=
If you use drones all the time, you can add a permanent entry to the kismet.conf file on your server:
ncsource=drone:host=
It seems that connecting to a drone over a wireless connection sometimes breaks the connection. The server will reconnect to the drone, but it's kinda messy.
If you have additions, or other platform specific tweaks, let me know @ render [at] renderlab.net
Many people contribted to this guide in meaningful ways and I wish to note thier contributions.
Dragorn, for Kismet and umpteen bug fixes and features. Michael Boyd for his early Kismet Newcore Drone work. The Whole OpenWRT team for thier work, especially whomever checked in the early Makefile for Kismet Newcore.