WarPig 1.0

I do a lot of wardriving for fun. I’m currently using Vistumbler on a Windows PC in my truck, or on the work PC. I have a DIY Wi-Fi / GPS dongle that I built a few years ago. At WiFiDB.net, i have contributed over 4.4 M APs.

The challenge is that, especially traveling for business, I don’t like to have to drag the PC along with me everywhere. This past week, in LA, I decided to look at building a new rig from an RPi to scan networks and make files readable to WiFiDB. I was originally thinking a script using iwlist and some gps calls, but then got derailed by the magic of kismet. This is that story.

I began here with the info from http://www.teambsf.com/warpi2dotoh/war-pi-2-1-building-with-pi3/ expecting to build a warpi box. However, i ended up using a stock distro build of kismet instead.

I call it WarPig 1.0 since it gobbles up storage like a pig, and the structure is likely a mess.

This RPi3B+ uses a USB GPS that cost me about $6 from eBay, and is currently using just a Ralink RT5370 Wi-Fi dongle because that worked. I’m ordering an Alfa dual-band device or maybe a pair, and when I get those I hope to expand the amount of frequency space I can monitor concurrently. I chose not to use the on-board Wi-Fi since it apparently needs a hack to put it into monitor mode, and this effort was yet another thing to do. Also, the on-board Wi-Fi doesn’t appear to allow an external antenna.

Start with new imaged SD card with Raspian buster with desktop but no apps

Through the raspi-config tool, give it a unique hostname, enabled SSH and VNC access

Run
sudo apt-get update
sudo apt-get upgrade

Set eth0 fixed IP address, you can change this as required for your own situation.

sudo nano /etc/dhcpcd.conf

# Example static IP configuration: interface eth0
static ip_address=192.168.1.10/24
static routers=192.168.1.1
static domain_name_servers=192.168.1.1

now modify /boot/config.txt to allow USB ports to output maximum current

add new line to the end of the file
max_usb_current=1

from https://learn.adafruit.com/adafruit-ultimate-gps-hat-for-raspberry-pi/use-gpsd

sudo apt-get install gpsd gpsd-clients python-gps

get rid of some old files that are no longer needed

sudo apt autoremove

Now, prevent systemd from running its own gpsd incantations.

sudo systemctl stop gpsd.socket
sudo systemctl disable gpsd.socket
sudo gpsd /dev/ttyAMA0 -F /var/run/gpsd.sock
sudo reboot

You may ask why all the reboots, they’re partially for caution to make sure I haven’t fatally corrupted something along the way. And believe me, I spent a good fraction of the day reflashing the SD card after corrupting something.

The following works on buster for a USB GPS device:
sudo /etc/default/gpsd
Add to gpsd the following:
START_DAEMON=”true”
DEVICES=”/dev/ttyAMA0″

sudo dpkg-reconfigure gpsd

sudo reboot

The following came from the teambsf link, maybe there’s a different way to do this, but this seems to work fine.

sudo nano GPSTimeUpdate

#!/bin/bash
#extracts time from GPS
GPSLINE=`gpspipe -w | head -10 | grep TPV | head -1`
#pull date and time from valid TPV line
GPSDATE=`echo $GPSLINE | sed -r ‘s/.*”time”:”([^”]*).*/\1/’`
#set system time to GPS time
date -s “$GPSDATE”

sudo chmod +x GPSTimeUpdate

sudo cp GPSTimeUpdate /usr/bin/.

sudo reboot

More from the teambsf group, this to make sure GPSTimeSet starts at boot.

sudo nano /etc/rc.local

#!/bin/sh -e #
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will “exit 0” on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
# Print the IP address
_IP=$(hostname -I) || true
if [ “$_IP” ]; then
printf “My IP address is %s\n” “$_IP”
fi

/usr/bin/GPSTimeUpdate

exit 0

And as always, do a sudo reboot

Set up a usb drive permanently for kismet log storage. I’m concerned about the thrashing to the RPi’s SDcard. In fact, this is just the beginning of an effort to eliminate all writes to the SDcard.

Insert a fresh USB thumb drive

ls -l /dev/disk/by-uuid/ gets the lists all connected drives, including the USB thumb drive.

sudo mkdir /media/usb-drive make a mount point

sudo chown -R pi:pi /media/usb-drive so that pi has access to this folder.

Make the drive an auto-mount at boot

sudo nano /etc/fstab

UUID=18A9-9943 /media/usb vfat auto,nofail,noatime,users,rw,uid=pi,gid=pi 0 0

put the UUID found from the ls command before. This appears to limit my ability to use any old USB thumb drive, dunno yet.

Install kismet from distro, I tried to compile it locally per the teambsf instructions, while it worked, it didn’t seem to be worth the extra effort.

Add some configuration details to kismet

in /etc/kismet/kismet.conf insert (or uncomment)
logprefix=/media/usb-drive/
writeinterval=120
ncsource=wlan1

cd /usr/local/etc sudo nano kismet.conf

sudo mkdir /home/pi/kismet

sudo chmod 777 /home/pi/kismet

cd /etc/init.d

have not yet implemented the below, which is from teambsf and is a way to auto-start kismet on boot. I don’t want this quite yet.

sudo nano kismet

#!/bin/sh #
#
# BEGIN INIT INFO
# Provides:              kismet
# Required-Start:     $all
# Required-Stop:     $local_fs $remote_fs $syslog $network
# Default-Start:         3 4 5
# Default-Stop:         0 1 6
# Short-Description:     Start kismet at boot time
# Description:         Starts kismet at boot time
#
#
# END INIT INFO
case “$1” in
start) echo “Starting kismet”
/bin/sleep 30
/usr/local/bin/kismet_server –daemonize
;;
stop)
echo “Stopping kismet”
killall kismet_server
;;
*)
echo “Usage: /etc/init.d/kismet start|stop”
exit 1
;;
esac

exit 0

sudo chmod +x kismet

Best way to start kismet at CLI

kismet_server >/dev/null 2>&1

starts kismet server and sends all output to dev/null

sudo update-rc.d kismet defaults

APRS-TW

APRS Telemetry Watcher is a simple, slick interface that connects (in my case) via a network connection to an RPi in my shack running dire wolf APRS software. APRS-TW looks for telemetry packets, then displays them in a nice graphical format.

Figure 1 – APRS-TW GUI showing two of my APRS stations’ telemetry values

It’s a simple piece of software, runs in a Windows environment, and the individual telemetry values, names, units, etc., can all be filled in the GUI so that the data that appears is already in engineering units. (i.e., instead of a telemetry value of “491”, it’s actually 12.73 Vdc.

This is handy. Is a nice complement to aprs.fi.

how not to be seen

With apologies to Monty Python.

While I’m not Mr. B. J. Smegma, I want to build another Desert Machine that I can place somewhere in the local desert.

Ok, so what’s a Desert Machine?

A long time ago, the original Desert Machine was conceived of, designed, built, tested, and placed out in the Mojave Desert by a group of us, some place in the Mid Hills / New York mountains area, next to an abandoned mine.

A simple box, consisting of a crystal-controlled 40-m transmitter producing maybe 1 W, connected to a “found” abandoned phone line wire strung along multiple decayed telephone poles, aligned in a row more or less allowing the transmitter to feed the NE end of the wire and the SW end of the wire pointing toward LA. A really simple telemetry circuit made of a pair of 555 timers, with one using a thermistor in the timing RC circuit, created a device that would wake up every ~30 minutes, send 10 dahs at a 5 wpm (or so) rate, and then return to sleep.

The timing between the dahs was based upon the ambient temperature; a little math at the receiving end would allow us monitoring the channel (something like 7043.0 MHz) to calculate the temperature at the box. It was loads of fun. Of course, this is completely against Part 97 rules, no ID, no person at the controls, etc., but it was super-cool to be able to tune in on the frequency back in LA, and if conditions were decent, be able to hear the transmission.

It turned out to be about 27 minutes between transmissions, and that drifted slowly over temperature. The crystal transmitter didn’t control the frequency too well; each dah was more of a doo-weep as the transmit frequency shifted a hundred Hz or so during the dah.

The whole thing was powered from a pair of 6 V lantern batteries (the carbon-zinc kind) and housed in some kind of plastic box that was reasonably closed.

Most surprisingly, the whole shebang lasted for about 6 months, growing steadily fainter and chirping worse and worse, until it was no longer hearable.

The device, in a pretty remote and obscure location, was not tampered with. The device was recovered eventually. Some kind of field mouse had built a home inside one of the compartments. The wire was left in place.

Now, how to do something similar but using a solar panel so that the battery lifetime issue is minimized?

Mysterious GPSD

I’ve followed a number of different directions, and each time I get results that differ. However, in the past 24 hours I’ve been using an ntp.conf file that I found here. This one has proved more reliable than the one that I got from frillip.com’s site. There’s little difference that I can see, but something made enough difference that I’ve been able to let the box reboot (pull power, or sudo reboot) several times and each time it comes back up properly. gpsd, ntpd, dire wolf, and the HP ADDC example.py all start running orderly and without mysteriosities.

I did discover that the fudge value for ntp seemed to be important – the link above used a time fudge of 0.5 seconds, and it was not reliably syncing on that. I moved time fudge to 0.3 seconds, and suddenly reliable. So I figure the offset between the GPS reported time and the pps from the GPS was tighter than the author at the above link was using (he was at 4800 baud, my GPS is at 9600 baud). I tried a time fudge of 0.0 and that seemed to work, but not all the time.

Figure 1 – ntpq -pn output showing ntp using my local GPS pps (“little o” at the beginning of the line)

Figure 2 is the results of the top command for the setup running all those processes.

Figure 2 – top command output

The unit is an RPiB3+, with USB sound card, GPS wired in on serial0, and the High-Precision AD/DA board as a hat. 15% CPU usage is pretty decent. dire wolf is definitely the most power hungry. I still haven’t connected a transceiver to this, so I’m just processing inbound received packets from a scanner’s audio output.

I have a Baofeng UV5 transceiver, and just liberated the mic cable from one of the $5 speaker-mics available on Amazon, so I’ll breadboard up a PTT interface now. The important thing with the PPT is that the RPi is 3.3 V logic level, and I need to pull down the Baofeng PTT line. I will use a 2N3904 NPN transistor as an open collector switch to do the job. I’ve also ordered some CMOS 555 timers in order to build a PTT timeout circuit, so that if the RPi hangs for some reason the radio won’t transmit indefinitely. Maybe 2 seconds for a PTT timeout?

raspberry pi – GPSD won’t reliably start

It appears that after all my toying around I still haven’t the *nix-fu chops to get everything to be stable. Every reboot sees gpsd not restart, but ntpd starts fine.

Found this note on satsignal.eu re challenges with gpsd. Tried the

$ sudo ln -s /lib/systemd/system/gpsd.service /etc/systemd/system/multi-user.target.wants/

command. Did a reboot. Now it starts automatically at reboot. Unfortunately, ntpd didn’t start this time. Thinking about “Whack-A-Mole”…

No, Really, the cat ate the GPS

Had fun this last Sunday building my first Stratum 1 NTP server. Got a couple NEO 7m GPS units from eBay, wired one up to an RPi3B+, and followed (not carefully enough) Phil Martin’s excellent tutorial on building a Stratum 1 server on a Raspberry Pi.

In preparation, I deployed one of my magnetic hockey-puck GPS antennas out on the balcony, and draped the coax run back to the bench. Soldered the SMA female on the GPS board. Wired the GPS to the RPi board. Screwed on the coax to the board. Applied power to all and got a CLI. Then … nothing. No lock. Picked up the board, inspected my soldering job, and as I was moving the board around, the GPS went into lock. Ah, something’s loose or cold solder joint.

Figure 1 – Successful stratum 1 NTP server using RPi and a $7 NEO-7m GPS

But no. Definitely touchy. Connected the uBlox app to the board, all the GPS signals, if there at all, were 30 dB down from where I’d expect them. A whole constellation of them, above the apartment, and none of them much more than 15 dB SNR. Moving the GPS module around, with its built-in ceramic antenna, helped, but still really poor.

Decided to drag the whole thing out on the balcony, and while following the coax cable that was supposed to be connected, in a single run, between the GPS SMA connector and the GPS antenna, discovered that it was now in two pieces. One connected to each device, but not to one another.

Damn cat(s) chewed through the coax. I think it was Sancho, but I don’t have the evidence to prove it.

Stratum 1 server now up and running flawlessly. As far as I can tell!

Figure 2 – ntpq -p output from the Raspberry Pi NTP server

UPDATE 01AUG19:

I connected the “High-Precision AD/DA Board” to the RPi. Got PiPyADC up and running. Noticed when I ran the example.py or example_2.py code the PPS LED on the GPS would stop blinking, though I’d get the following kind of output (see Figure 3).

Figure 3 – PiPyADC example_2.py output

Discovered that this board uses P0 – P4 for control. Was causing the P1 line to do weird things. Moved the GPIO for the PPS input from the GPS from BCM18 (GPIO P1, header pin 12) to BCM24 (GPIO P5, header pin 18). A reboot and all is good.

The Pi is now running a Stratum 1 NTP server, direwolf decoding APRS packets on 144.39 MHz, and reading the ADCs on the AD/DA board. Now to figure out how to get the ADC data into APRS telemetry packets.

Lightning can kill, destroy, and maim

… people, and especially electronics, when those electronics are out in the desert at a radio comms site.

http://By Catalin.Fatu, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=3814649

There are a variety of methods developed by others to determine a location’s susceptibility to lightning strikes. Certainly, there’s the question of whether a given location ever gets much in the way of weather that can generate lightning strikes (think LA), but nonetheless, it’s important to realize that bolts from the blue can happen, and when they do, what precautions has a design in place to limit the potential damage.

The little radio site atop Oatman is one of those locations where lightning is probable, at least when there’s that kind of weather somewhere nearby. As well, in one of my day-job jobs, there’s all sorts of lightning strike considerations being done in the design. I get to learn from the experts, there!

A lightning strike is a funny critter – one can never predict precisely when and where the current will go. Plasma physics, air composition, charge distribution, airborne particulates, surface characteristics, probably way more factors. In engineering, one tries to offer “tantalizing” targets for the lightning. But while those targets are only suggestions, they do help quite a lot in terms of the statistical probability of the lightning hitting something that wasn’t intended as a target.

While doing some research for the day job on the rolling-sphere method of lightning protection, I came across this gem of a discription.

From https://greymattersglobal.com/rolling-sphere-method/

It just gives such a sense of predation to the lightning. Not that lightning has that, but kind of cool description nontheless.

Off grid in Arizona

I have a (very small) radio comms site in southwest Arizona, atop Oatman Peak/Hill. Only 1400′ or so in elevation, it’s a clear view from there to perhaps 50 miles of I-8; it’s also a clear radio view to about 100 miles of UPRR Gila Subdivision railroad.

The problem is that right now I do not have commercial power. Not to worry! This is Arizona and there’s 350 days of sun.

Today I swapped out the 15 year-old 125 Kyocera solar panel with a Rich Solar 190 W panel. Essentially the same physical size. Way more efficient. I only messed up one of the 4 stainless steel bolts that hold the panel in place, it galled before I could get a quarter turn on the nut. Nonetheless, I was able to put the new panel in place, and the dc current went up around 25% and the high side voltage from 17+ to 21+ volts.

Figure 1 – New 190 W Solar Panel Installed at Oatman

Yes, there’s a power line drop from APS, but there’s no meter. To get a meter, I’ll have to first have APS remove the drop, call the county to get a permit for a new electric service, replace the ancient entrance panel with a modern one, get the county to come out and inspect, then call APS to reconnect the feed. It’s fun, but it takes time.

But now, with 190 W of peak solar on the mast, I have enough to run a 15-17 W dc load continuous, even through three days of winter storms. And if I upgrade the batteries to 24 Vdc, maybe 18-20 W! Lordy-be. Makes you realize how hard it is to be off-grid.

Makita LXT TOOLs – the FLAMING truth

I learned something this morning, after not learning it for some time now. My large capacity (6.0 AH) Makita batteries don’t fit on my portable Makita angle grinder. At first, I thought it was some minor thing like when I’d bought some off-brand batteries and they just didn’t fit the slide very well. But NO!

One of the things I’ve consistently noted about the angle grinder is that it appears to have a thermal cutoff circuit in the tool, and will shut down the tool after heavy (or sometimes, not so heavy) usage. Working outside in the desert in summer causes it to trigger regularly, which is annoying to the point of unusable sometimes. I also note that it only seems to happen on old batteries or batteries that don’t have much charge left.

I bought a few months back some Makita 6.0 AH batteries. Brand new. Came fully charged as well in original Makita packaging. Cost plenty. Interestingly, they fit on all my tools but the angle grinder. And just now, I learned why: on the angle grinder, there’s a plastic nub protruding on the battery slide that prevents the battery from engaging. See Figure 1.

Figure 1 – Makita BGA542 Angle Grinder and the Nub

On-line, people talk about filing/cutting the nub off, and that obviously solves the issue of the battery mate. Bu others pointed out there’s circuitry missing in the older tools that is important to managing the battery capacity and preventing over-depletion. Ok, I’ll buy that, except:

I bought most of my Makita tools as a kit, back in 2006 or so. Angle grinder, circular saw, drill, impact driver, flashlight, charger, two 3.0 AH batteries, and the all-important “sawzall” tool. And none of them, except the grinder, have that nub! Just last month, I bought an orbital sander and a mini-shop vac. Interestingly, the orbital sander has a microswitch where the nub would be, and a third contact (Figure 2). So, that appears to allow the sander to detect the difference between batteries, and apparently do something about it.

Figure 2 – Microswitch and 3rd Rail Contact, Makita Orbital Sander

I am convinced that there’s a good technical reason for the nub, but since it’s only on the grinder, and the grinder’s more than 10 years old, that I just might consider removing that nub and taking the risk that the tool goes up in flames.

UPDATE: I actually found and read the manual. Figure 3 shows the important bits about overload and battery indicators.

Figure 3 – Makita BGA452 Users Manual Excerpt

That certainly makes sense based upon my observations. And here’s a bit of unintended irony:

Figure 4 – Makita BGA452 Battery Cartridge Storage Temperature Caution

It got to 117 deg F yesterday at the site. Not sure how to manage this item. Wear gloves and eye protection, to be sure!

Experimenting With MPG123 on Raspberry Pi

Last weekend I loaded mpg123 on a spare RPi here at the lab.

Figure 1 – RPi 3B Running mpg123

I haven’t enabled the USB sound dongle yet, but would like to do that. However, I wanted to see if I could get audio from the Internet routed through the HDMI display speakers. And indeed I could!

Next step was getting railroadradio.net to stream through the same setup. I know that railroadradio uses .pls files, and not obviously mp3, so I did a quick search to see if there was a way to get mpg123 to do what I wanted. And indeed there was!

http://www.linux-magazine.com/Online/Blogs/Productivity-Sauce/Stream-Internet-Radio-from-the-Command-Line-with-mpg123

The above link gave me the secret, courtesy of “Alex”, where playing a .pls file just needed the “-@” option in the mpg123 command line. So now, I’m streaming railroadradio’s Southern California BNSF/UP/Metrolink audio.

Figure 2 – RPi CLI showing successful streaming of Internet-sourced .pls audio stream

Later, I’ll get the dongle running as a line input from one of my scanners, so that I can get the RPi to be a feed server. Will have to learn more about jack1 and jack2…

Commentary and insight on many topics, sometimes even about wireless

WP Twitter Auto Publish Powered By : XYZScripts.com