War walking with a Raspberry Pi 0 W.

Apr 28 2019

You've probably noticed from the datestamps of my last couple of weeks worth of posts that they were autoposted by an agent.  This is because work has taken a turn for the extremely busy and I haven't had the time or the energy to write anything in particular; certainly nothing really useful.  Rather than wasting everybody's time I decided to relax a bit by picking up an older project, namely a new war-walking rig, and making it work.  Since I wrote that original post a few more security updates have come out for my phone and broke not only the Wigle wardriving app but a couple of other things that I really like, but that's neither here nor there.  I'm still using the equipment outlined in the previous post and the latest Git commit of Kismet right out of the developers' repo.  I made a couple of design decisions that I'll discuss later which are specific to my use case, which you are free to ignore or discard as you deem necessary.

First off, I solved the problem of not having enough processing power to compile Kismet by popping the microSD card out of my RasPi0w and installing it into a spare RaspberryPi 3b+ I had on my shelf.  I ran through the quickstart procedure as documented without having to change anything.  The only real thing I had to do was wait because it took an hour or two for Kismet to compile.  I don't know if I could have sped it up any - maybe a faster microSD card, maybe using all four CPUs on the unit instead of just one (because I didn't want to risk overloading and crashing another RasPi, not having the patience to fight that particular battle at the time).  I had no particular deadline or schedule, so it didn't cause any real bother to go the long way around.  While Kismet was compiling, I went scrounging around in my parts bins for a few other things I knew I'd need, like a USB hub and a power bank that would run the entire rig for at least twelve hours at a stretch (my estimate later proved fairly accurate).  My component arrangement could probably use some work.  I could probably get a better cable layout with a USB squid of some kind and a handful of zipties, but I'll worry about that later.

One of the things I did was leave the built-in wireless NIC active, so that it would connect to my home wireless network when I got home.  This makes it easier to log into my wardriving rig and shut it down cleanly.  The external wifi NIC does all the work of scanning for access points.  I know that I could do something like rig up a button that tells the RasPi to shut down when somebody presses it but that would require a bit more electrical work than I have time for at this moment.  Maybe I'll figure out how to build a little USB device that does the same thing...

I also set up a systemd .service file that automatically starts Kismet on boot and shuts it down cleanly when the RasPi shuts down.  A sample .service file is provided in the Kismet source code, so this was a trivial operation.

Because the RasPiW does not have an internal clock (and there isn't room to install one in the housing) Raspbian queries the nearest known time servers at boot to set its system clock.  If it can't (and if I'm in the field, away from my home network (which is the only one configured) this is the case) the system clock won't be set properly, which means the timestamps on what Kismet records will be wrong, which means that short of database surgery (newer versions of Kismet use SQLite databases instead of flat files) the map results can't be uploaded, in which case there's no point.  To solve this particular problem I have my RasPiW set its system clock from the GPS receiver, which I posted a howto for late last year.  Initial tests seem promising.

Now, a couple of things I still need to figure out:

Kismet, if it's been running for a while (two or three hours) tends to suck up a lot of RAM.  When SSHing into my RasPiW at home, I found that it sometimes took a couple of tries to cleanly shut down the unit due to "out of memory" errors.  I was entirely unsuccessful when trying to cleanly kill Kismet (sudo systemctl stop kismet.service); the command would hang forever and I'd have to resort to a clean shutdown.  This means that to get at the Kismet databases I have to crack the case open, extract the microSD card, plug it into Windbringer, and manually copy the files over so I can convert them into the format that Wigle expects.  This also means that I have to have another copy of Kismet installed elsewhere, which works but isn't an elegant solution.  The best case scenario would be that I SSH into the wardriving unit, shut down Kismet, run the conversion on the RasPiW, and download the resulting files.

When uploading mapping data to Wigle, the site suggests also uploading the data to Open Streetmap to add to their cartographic database.  I've not yet figured out how to do this because the recommended utility doesn't seem to work with newer versions of Kismet.  Specifically, it seems to be expecting XML data dumps instead of SQLite databases.  I don't know if there are existing tools that will do this so I might have to write one myself.  We'll see.

While it's not really necessary, it might be nice to add a tiny display to my wardriving rig, if only so I can keep an eye on where it is in the shutdown process.  The RasPi zeroW has a miniature HDMI jack so I can use that but I don't yet know if suitably tiny displays (on the order of the dimensions of said RasPi) exist.  Maybe it would make more sense to use the built-in Bluetooth capability of the zero W to link it to my phone.  I'll have to play around a little and figure out how to do it.  Perhaps another project will come of it.