Within the hacker community, war driving is a common pastime, and the astonishing lack of security of most access points is well known. To the public at large, the problem is less well known, in spite of increasing news coverage over the last year or so. While I've used a number of "off-the-shelf" wardriving packages (NetStumbler, BSD Airtools, Kismet, etc.), none of them did quite what I wanted in the way I wanted (for example, write data to a relational database). In the hacker spirit, I wrote my own wardriver system on FreeBSD using MySQL as the database back-end. This allows me to generate reports such as looking for access points which have moved, have had the SSID changed, have been turned off, etc. all in real-time as I drive.

I spent about two months playing with this setup in my truck, running it almost 100% of the time whenever I drove anywhere, constantly tweaking, debugging, and adding features (sometimes pulling over to the side of the road to fix bugs on the spot). Along they way, I mapped over five hundred access points around the Seattle area. I was also able to do fun things like generate a map of everywhere I had driven for any given time period, or generate maps showing all of the access points for a given area. After a while, though, the fun started to wear off, and I began looking for a new project.

On 1.Feb.03, the Space Shuttle Columbia disintegrated on re-entry, killing all aboard. As the engineers have try to re-construct the sequence of events, they continuously refer to real-time telemetry coming down from the shuttle, and how that allows them to monitor the thousands of sensors and systems aboard the shuttle. The telemetry dropped out for about 25 seconds after the last voice transmission, then picked up again for two more seconds before the spacecraft was destroyed by aerodynamic forces. This got me to thinking about telemetry. With my homebrew wardriving setup and plenty of servers at home, I had all the hardware I needed to experiment with some telemetry of my own.

My theory was that instead of simply detecting access points, I could launch a DHCP request, and if I receive an address, try to ping a known address on the open Internet. Assuming the ping was successful, I then, in theory, have a path back to my server, though for a very short duration as I drive out of range of the access point. My original thought was to open an ssh session and transport the data home over the ssh link. I went back to my several months worth of data sitting in MySQL, and looked to see how long I was in range of the average access point. Turns out anywhere from one second up to almost thirty seconds (wonder what kind of antenna those guys are using?). On average, though, it was more like ten to fifteen seconds. By the time you get a DHCP address, do a ping, open an ssh session, and start sending data, the signal is gone. Plan B. The more I thought about it, the more I realized that ssh was a bad idea, even if it had worked. While having a complete detailed record of everything you're measuring is important, that task is probably best accomplished on the vehicle itself (ie, data records on-board the space shuttle, or in MySQL in my pickup). With telemetry, it's more important that the data be "right now" than complete. Missing frames can be tolerated, but high latency (ie, TCP time-outs and re-transmissions) make watching live data useless. In addition, when the link dies (as it inevitably does if you're driving), you're left with an ssh process (and it's associated TCP session) hanging around until it finally times out and dies. This led me to the opposite end on the "overhead scale": stuff the telemetry data into UDP packets, one packet per second per sensor, and throw them blindly at the server so long as the link stays up.

Real-world testing shows that this was the right thing to do. Comparing the on-board database with the data received at the server at home shows that somewhat in excess of 95% of the packets that are sent while the signal strength is reasonable arrive complete and uncorrupted at the server.

The system has two pieces: the mobile system installed in the truck, and the server installed in my basement. The mobile server consists of a number of daemons, each providing a service (reading the GPS, reading the network card, etc), and sending that data in a stream to a main "display server", which displays all of the accumulated data on one integrated screen. The data is also passed to a database server for archiving (and geographic and access point look-ups), to a software voice synthesizer (so I don't have to watch the computer screen while I'm driving), and back to home whenever a valid link exists. The mobile system consists of these parts:

• gpsd.pl - This daemon communicates with the GPS receiver using NMEA-0183 and decodes each NMEA string into it's various parts. This daemon sends two packets per second, one containing information on each of the satellites in view, including azimuth, elevation, and signal strength. The second packet contains navigation data, including latitude, longitude, map datum, magnetic deviation, altitude, course, speed, horizontal and vertical dilution of precision, quality of fix, etc. This daemon should (in theory) work with any NMEA-producing device (different brands of GPS receiver, LORAN receivers, etc.), but to date has only been tested with Garmin receivers (a GPS12xl, an eMap, and a GPS16). This daemon can also send waypoints to the GPS, if desired.
• netd.pl - This daemon "manages" the wireless card and related networking functions. It probes once per second for access points within range, starts and stops the DHCP daemon as required, pings once a DHCP address is received, and reports signal strenth, signal quality, SNR, SSID, BSSID, channel, etc. back to the display process. It also reconfigures the IPFilter firewall and IPNAT NAT daemon on-the-fly to provide Internet access to the internal truck LAN when a valid Internet connection is present. This daemon reports once per second. This daemon also provides a live NMEA-0183 data stream on TCP port 4002 on the LAN ethernet. I have a "TCP-to-fake-serial-port" client called DeviceComm on my Windows machine that allows me to use a virtual COM4 serial port to connect across the truck LAN to the GPS receiver for use with Street Atlas 2003, VisualGPS, USAPhotoMap, and a few other goodies.

• iod.pl - The I/O daemon talks to a 14-channel digital I/O board made by Weeder Technologies that is used for controlling the system and reporting status. There are four switches, four red LEDs, four green LEDs, and a buzzer attached to the interface. The switches control whether or not the system attempts to connect to target networks, turns the voice synthesizer on and off, and shuts the system down. The LEDs indicate status, such as "new access point visible", "known access point visible", "Internet connection available", as well as various faults. All of this information and control is also available at the computer keyboard, but the external control box allows control of the system with the laptop stowed underneath or behind the seat.
• talkd.pl - The talk daemon receives events and status from the other daemons, and audibly announces events and status on a periodic basis, for example "access point found", "open access point found", "battery status low", "external power failure", speed and direction, etc.
• powerd.pl - The power daemon watches the laptop power and battery status and reports every twenty seconds. Two separate packets are sent, one for A/C (external) power state and one for remaining battery life. This information is pulled from APM.
• ricod.pl - This daemon queries my Ricochet modem once per second with "ATS311?" to gather information on active pole-top radios for the Ricochet Pole-top Mapping Project.
• emeterd.pl - This daemon monitors the batteries that power the system via a Xantrex Link 10 E-Meter with RS-232 option. While the vehicle's engine is running, the system is powered from the vehicle's electrical system (which also charges the batteries). When the vehicle is turned off, power is drawn from two 85Ah deep cycle gel cell batteries behind the seat. These batteries are capable of powering the laptop and GPS receiver for approximately 50 hours, or powering the entire LAN (and associated equipment including a second (MS Windows) laptop, a hub, a VoIP phone, a Kenwood TM-D700A ham radio, and a few other goodies) for approximately 20 hours, assuming an 80% discharge floor. The E-Meter provides 1-second interval updates on battery voltage, charge/drain amps, amp-hours remaining, time remaining at current rate of discharge, and battery temperature. This information is parsed and reformatted by the daemon and provided to the display process at one-second intervals.
• dbd.pl - This daemon talks to the database, and is responsible for archiving all data from all sources, as well as answering queries about nearby access points, geographical features, etc. The database back-end can be MySQL, dbm files, or flat ASCII files. The database is pre-loaded with sites from the Geocaching web site as well as geographic information I obtained from the USGS "Place Names" web site, converted to comma-separated-values, and loaded into MySQL. While this is kind of slick, it's not perfect, as the USGS data uses the NAD27 map datum, and everything else in the system uses WGS84. This causes what appear to errors of up to 200 yards in the USGS data (not to mention the fact that the USGS data is very out-of-date, and chock full of genuine errors). At some point, I'll code up a little function to convert from NAD27 to WGS84 and back to eliminate at least part of the problem by converting the data at load-time (to reduce the overhead of doing the computations in real-time).

• display.pl - This is the main display server. It is coded in Perl and uses curses to have a "pretty" output. It displays the status of each daemon, all of the navigational information, information on the satellites used to generate the navigational fix, and all of the wireless network information. In addition, the display process forwards all data to the database daemon, forwards all data to the home server (when a valid Internet connection is available), and forwards selected information to the voice synthesizer.

The home (ie, server) system has two parts. There is a daemon that listens for incoming UDP packets from the truck and records them in a database (well, currently in a flat file). There is also a modified version of the display.pl code that can read data from a flat file or from MySQL and "re-play" a trip from recorded data, including power, navigation, and network information, much like the stuff you see on tv after they pull data from crashed plane's "black box".

The system has been more-or-less complete and functional for about a week. So far, it works exactly as hoped, except for one small problem. There seems to be a problem with the Lucent wireless card driver that causes the driver to freak out (ie, freeze) sometimes when more than one network can be seen from a given spot, and no "desired SSID" is specified (ie, connect to "ANY"). This causes the whole system to hang, and requires a hard reset. I'd like to replace the Lucent card with a Senao card, anyway (a PRISM-based card with about four times the power output). This should solve that problem.

What now? Now that the basic system is working, I've put together a second duplicate system (minus the deep-cycle batteries and E-Meter). I've done a little bit of testing with having both systems mobile (one in my truck and one in my wife's), and modifying the code a bit to send navigational data between the two trucks. This allows a number of cool things, like allowing the kids to type back and forth from one vehicle to another on a road trip, and also giving a constant real-time voice update on the location of the other vehicle (ie, "other vehicle is 250 yards behind, gaining at 5.7 miles per hour").

There's lots of fun things you could do with mobile Internet access, even if it's in very small bursts (come on, Metricom, give us our Ricochet back, please!). It would also be simple enough to write a message-passing system, perhaps to queue and forward instant messages, maybe a client to grab updated weather information as you drive, or maybe even get live traffic updates from the slick Washington DOT traffic ftp/http server.

The density of access points from Everett, WA (north of Seattle) all the way down to Portland, OR is remarkable. I rarely go more than a minute or two, whether in an urban or a suburban area, without hitting an open access point. Even out on the highway in the middle of nowhere, I hit a surprising number of access points apparently located in warehouses and other businesses along the road. At least one every ten miles or so. If one were a bit less than perfectly honest, there are a number of nifty commercial applications for something like this. For example, a dispatch system for taxis or other services, a vehicle tracking system for delivery trucks or rental cars, or even a paging system.

One of the enhancements I need to make is to pass the NMEA-0183 data from the GPS16 back on out a serial port to the Kenwood APRS radio. This would eliminate the need for two GPS receivers in the truck, plus, I could intercept the waypoint updates sent from the radio to the GPS and save them in the database.