I’ve been planning to put one of my older Raspberry Pi devices to use as a “War Pi,” based on a SANS Reading Room whitepaper by Scott Christie titled “WAR PI”. This article is the adventure that got me to finally being ready to build the War Pi. The adventure took a few wrong turns right around the GPS area…
Gathering the Parts
There are a few items needed to make the War Pi:
- Raspberry Pi (I have two 256 MB Pis and one 512 MB Pi – I’m starting with the latter)
- USB 802.11 wireless device capabale of packet injection (I have an Alfa Networks AWUS036NH which I use for a variety of wireless ‘research’ projects)
- USB GPS receiver (I mentioned in an earlier blog post that I found an old Microsoft Streets and Trips GPS unit, and got it working on Linux Mint; that’s what I’m using with my War Pi)
- Power supply (don’t have one yet – I may have to make one today, or just pick one up at a local store)
Here they are, all ready to use:
I had a 4 GB MicroSD card I wanted to use, but for some reason it can’t be recognized by Windows or by the Pi. I have research to do here…
Initial Boot and Config
I finally found an 8 GB card with a fresh (but outdated) Pi image. I modified a few settings in raspi-config:
- Medium overclock
- Enabled SSH server
- Boot direct to desktop
- Expanded the image to fill the card
And with that, I see a beautiful fresh desktop:
Next, I’ll admit – I cheated a bit and used the WiFi Config rather than editing the wifi by hand. Call it lazy, or say I checked in my engineer card… Regardless, I set up my Alfa wireless device temporarily so I could update the Pi. First a quick
sudo apt-get update
and then a
sudo apt-get upgrade
brought me up-to-date. Of course, it’s always good to do this more than once, since dependencies are being updated and sometimes multiple rounds are helpful. Sure enough, round two resulted in another 205 MB of updates. Clearly I started with an old build of Raspbian. And not surprisingly, my Pi died in the midst of the second update – sometimes that happens.
I probably should have started with a latest OS image, but my luck reading and writing images to SD cards lately has been pretty bad, so I decided to just power through upgrading. As an aside, the full upgrade lasted over an hour—it pays to take this in little bites!
USB Conflicts
I ran into a very interesting issue – as I was adding peripherals to perform various tasks (like plugging in my wireless device or my GPS), I had a really tough time getting them to all work together happily. When I plugged in high-draw devices like the GPS, the Pi would reboot. Upon reboot, the mouse and keyboard wouldn’t work. I think there are a couple things at play here: insufficient power availability on the Pi (meaning I need a powered USB hub) and/or IRQ assignment conflicts.
UPDATE: using a powered 10-port USB replicator, I am not only running with all 4 peripherals (keyboard, mouse, Alpha and GPS), but I’m doing it without supplying power to the Pi. Interesting…
War Pi Setup
With the Pi updated, it’s time to install the main tools for War Pi: minicom, GPSD and Kismet.
- The minicom tool isn’t called for in the whitepaper, but it’s a nice lightweight tool for proving a GPS is working.
- GPSD is a tool for interacting with GPS. Kismet can read directly from most GPS units, so GPSD should just be there as backup, but sometimes GPSD can read from a GPS which Kismet cannot, and then Kismet can read from GPSD.
- Kismet is an 802.11 wireless utility for detecting, sniffing, and interacting with wireless networks.
MiniCom
Setting up MiniCom was easy – just follow the instructions on my blog post about getting a Microsoft Streets and Trips GPS unit working in linux. I was able to use MiniCom to show my GPS was working – important, because I had a lot of trouble in the next step (GPSD).
GPSD
So now that the Pi is updated and running reliably, it’s time to move ahead with the WarPi instructions – next step is setting up GPSD. This was relatively easy, although something happened the first time I ran apt-get install gpsd, so when I tried the sudo dpkg-reconfigure gpsd, it failed to launch. Rerunning apt-get install gpsd fixed it.
Once GPSD was installed and configured as per the instructions, I rebooted and started the CGPS client. Interestingly enough, the GPS just started sending garbage. CGPS kept showing the GPS couldn’t connect. When I disabled GPSD and rebooted, I booted minicom and it showed nothing but garbled text. After an hour of troubleshooting (including connecting it to my linux box where it worked perfectly), still no joy. I gave up for the night.
UPDATE: in reading around, I discovered these SirF GPS receivers are quite touchy. I’m working on another blog post about them, but basically if you use a SiRF receiver with GPSD, GPSD puts it into binary mode simply because the way it determines whether or not the GPS is a SiRF device is by sending a –b command. Heisenberg in action…
By waiting 3 days, the GPS resets itself back to NMEA mode (which I’ve confirmed in minicom). Now I’m having trouble because the “Validity” bit (sixth bit in the NMEA string) is showing “V”. You’d think that means “Valid” but it actually means “WARNING”. I’ve heard these old Streets and Trips GPS units can require quite some time before picking up satellites, so I’m going to let it sit for a couple hours and see what happens.
New GPS, New Hope
Like the Jedi rising from the ashes, my new GlobalSat USB BU-353S4 worked perfectly out of the box when connected to minicom on my Linux box. I’m going to start up a new step-by-step in another blog entry, to cover the actual build process.
Lots was learned about serial communications, SiRF, and GPS. But now it’s time to go war Pi’ing.
No comments:
Post a Comment