Mobile Weather Balloon Chasing Rig

A few locals (mostly part of the SecKC crew) have been chasing weather balloons for the past few months. It's an interesting way to get out of the house and go do something. We are also trying to reverse engineer the guts of these weather balloon payloads, but that's a story for another post.

Weather Balloons and Radiosondes

In the US, a number of National Weather Service offices (I'm guessing about a third to half of them) deploy weather balloons every day at about 0:00 and 12:00 UTC, give or take an hour either way. They often launch at about 45 minutes ahead of time, but they can be delayed by severe weather. That's over 700 weather balloons per year from each of the dozens of stations that launch them!

The weather balloons carry something called a radiosonde into the stratosphere. This package contains a battery, radio transmitter, GPS, and weather sensors. The radio transmissions include position information, humidity, temperature and other metrics, once per second. Position information is used to determine wind speed and elevation to correlate with the other metrics. This data is shared internationally and is used for local forecasts and models, and worldwide climate trends. 

Close up of the bottom panel of a 400 MHz Lockheed-Martin Sippican LMS-6 Radiosonde.

The air gets thinner and the pressure lowers as the balloon climbs past 100,000 feet, and it eventually bursts. The package, weighing less than a pound, falls back to the ground under a small parachute so that it doesn't hurt anyone or anything when it lands. 

Here's a video I shot through a telescope, of a weather balloon bursting at about 130,000 feet. You can faintly see the radiosonde swinging beneath the balloon. When it bursts, the parachute expands as the package falls.

 

A recovered weather balloon, after untangling all of the rope.

The National Weather Service does not recover these devices from the field. Some of them have a mailing bag and shipping label attached so that folks who find them can return them to be refurbished. The radiosondes that we've been finding have no instructions aside from "dispose safely". That is to say, once they have fulfilled their mission and landed, these radiosondes are very much "finders keepers" and are no longer government property. They can land more than a hundred miles away from the launch site, depending on jet streams and wind conditions closer to the surface.

Tracking

To facilitate the tracking of these devices, a number of software tools have been created to make use of software-defined radio receivers (such as the RTL-SDR or HackRF One) or simple audio-decoding from a computer sound card. My favorite tools are radiosonde_auto_rx and chasemapper, both part of Project Horus, an amateur radio high-altitude-ballooning project in Australia. The tools to monitor amateur balloons happens to work just fine for tracking weather balloons, and folks have added code to help decode the payload data for weather balloons. 

radiosonde_auto_rx scans a small range of frequencies you define, looking for a signal that's likely to be a radiosonde. It then tunes to that frequency and tries to decode the location data. Once it's locked on, it continuously tracks the location of the balloon. It can also upload balloon location data to websites like sondehub (radiosonde tracking) and habhub (high-altitude balloon tracking), so folks can share data about these balloons' trajectories with a world-wide audience.

Screen shot from sondehub.org showing multiple weather balloons in flight, and locations of auto_rx sites:

Chasemapper acquires the balloon location data from radiosonde_auto_rx, and your location from local GPS data, then draws a map of your location and the payload's location, in a browser session. This is a nice visual aid when you're planning on recovering a radiosonde. Here's a screen shot showing my vehicle's track and a radiosonde payload location on a recent balloon chase. The payload location doesn't have a track following it because I rebooted my setup to move it to my car. The movement was from me hiking toward my car while unplugging the battery.

Building the mobile tracker

I decided I'd like to build a semi-mobile balloon tracker that I could leave running at home most of the time, but also quickly toss into my car or even carry with me if a radiosonde was going to be landing nearby, to help me recover it from some corn field or woods or an 8-foot tall patch of thistles and prairie grass out in the middle of nowhere. These things never seem to land anywhere convenient, like in the ditch of a dirt road. 

I decided to make do with stuff I already had laying around. You may recognize some pieces from previous articles. The below links are Amazon affiliate links to the parts I used if you wish to reproduce my exact setup, and purchasing from these links supports this site).

• Raspberry Pi 3 with an AdaFruit 3.5" TFT
• RTL-SDR v3 receiver kit or NooElec NESDR Nano Three kit (you only need one SDR, both of these models work in this setup)
• Inseego MiFi 8800L WiFi Hot-Spot
• Rii wireless mini keyboard/trackpad
• 26800mAh USB battery pack

The MiFi 8800L not only offers 4G wireless connectivity so radiosonde_auto_rx can upload location data and chasemapper can download map data, but it also has a GPSd server integrated so other devices (like the Raspberry Pi) can use the GPS location of the hotspot. You must log in to the MiFi admin page to activate the GPS Service. By default, it runs on port 11010, and it's recommended to leave that default set.

Actually getting chasemapper to use that GPS data turned out to be more trouble than I had bargained for. You may be better-off connecting a USB GPS to your Raspberry Pi. I'll cover how I managed to cobble everything together as I go through this post. 

The first order of business was installing the latest RasPiOS to a fresh 16GB SD Card. There is more than enough documentation on raspberrypi.org to get you started. The Rii keyboard works both with a nano-receiver or via Bluetooth. Pick your poison. I chose to use the nano-receiver because bluetooth seems to not like to auto-reconnect on reboot some of the time. Feel free to use whatever kind-of-portable human-interface device you like.

Next, I had to get the display working. 

I had really good luck with the fbcp-ili3941 driver on this Raspberry Pi with Kali Linux, and the instructions I wrote about setting up fbcp worked fine on the latest RasPiOS. You can follow most of the instructions in that article to get the AdaFruit TFT working, just keep in mind the touch screen won't work with the fbcp driver. The digitizer on my display actually broke a few years ago, so I don't miss it.

For my setup, I uncommented the following lines in config.h. Note that these lines need the # at the beginning of the line. I removed the // from these two lines to uncomment them:

#define DISPLAY_ROTATE_180_DEGREES

#define DISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING

I used the following options to build fbcp:

cmake -DADAFRUIT_HX8357D_PITFT=ON -DSPI_BUS_CLOCK_DIVISOR=30 ..

As per the Kali instructions, I put the call to /usr/local/bin/fbcp near the top of /etc/rc.local so that it runs on boot.

I set my display up to run in 480p mode since the display is so tiny. The entirety of my /boot/config.txt file is:

hdmi_force_hotplug=1

dtparam=audio=on

hdmi_group=1 

hdmi_mode=3 

dtoverlay=pwm,pin=18,func=2

Reboot and make sure the TFT display works.

Now for Radiosonde_auto_rx. The setup instructions mostly work. You'll need to install a bunch of dependencies. They recommend installing rtl-sdr from source. I just added it via apt, and it supported the bias-tee option. Make sure you install the udev rules and module blacklist options per the instructions. 

Keep following the instructions. Maybe, if you're lucky it'll just work. For me, though, I had to do some hacky garbage to get it to compile. If build.sh fails, you can try these tricks: 

I had to tell the compiler use the c11 standard for compiling fsk_demod by adding “-std=c11” to line 50 of auto_rx/build.sh, which now looks like this:

gcc -std=c11 fsk_demod.c fsk.c modem_stats.c kiss_fftr.c kiss_fft.c -lm -o fsk_demod

I had to tell the compiler to use the built-in alloca() for some reason, and the real baffler was having to define the meaning of freaking Pi, twice.

In utils/fsk.c, I added these lines to the "includes" block near the top:

#define alloca(x)  __builtin_alloca(x)

#ifndef M_PI

    #define M_PI 3.14159265358979323846

#endif

And I added the following to utils/modem_stats.c, also near the top. 

#ifndef M_PI

    #define M_PI 3.14159265358979323846

#endif

With all that out of the way, the instructions for setting up Radiosonde_auto_rx work just fine. Make sure to edit station.cfg. You probably want to specify a name, callsign or handle for uploading to HabHub (and enable uploads), and you should specify your latitude and longitude. You could, in theory, also use gpsd for radiosonde_auto_rx as well. I didn't set up auto_rx to use gpsd, so even when I'm mobile, the reports appear to come from the hard-coded location in auto_rx. I'm fine with that.

It seems that the National Weather Service relies mostly on radiosondes made by Lockheed Martin Sippican. The LMS-6 Radiosonde comes in two "flavors", one operating between 400 and 406 MHz and the other one operating around 1680 MHz. The Vaisala RS41 is a newer radiosonde model used at some locations, and it also operates around 400 MHz. You should ensure the proper frequency range for your location is enabled. The 1680  MHz radiosondes also work best with a circular-polarized antenna, similar to those you might use for certain FPV drone video.

Setting up Chasemapper

The instructions for Chasemapper mostly work out of the box, with the exception of GPSd in my case. The version of GPSd on the MiFi 8800L doesn't support JSON output which Chasemapper requires, so I ended up running a modern version of  GPSd on RasPiOS, pointing it at the GPSd on the hot-spot. Details on that toward the end of the article. I also had some trouble running GPSd on the default port of 2947, so of course I ran it on port 1337. 

For horusmapper.cfg, I changed only the following lines:

car_source_type = gpsd 

gpsd_port = 1337

habitat_call = [my amateur radio callsign]

Tying it all together

I didn't set up systemd services for anything, but you may want to follow the instructions in the git repositories to enable systemd services if you plan on building a dedicated tracker. I run gpsd, auto_rx and chasemapper on-demand with a simple shell script that I call "loon.sh":

#!/bin/sh

gpsd -S 1337 gpsd://192.168.1.1:11010

cd ~/radiosonde_auto_rx/auto_rx

python auto_rx.py&

cd ~/chasemapper/

python horusmapper.py&

Everything runs in the background, and the terminal will fill up with logs about both chasemapper and auto_rx status. You can fire up your Raspberry Pi's web browser and hit localhost:5001 for ChaseMapper, and localhost:5000 for the auto_rx status page. 

AppSec Lab: RasPwn with a MiFi-8800L JetPack Router

I'm hosting a few Application Security workshops later this year. I settled on RasPwn for the lab because it comes pre-configured with a bunch of vulnerable applications out of the box.

RasPwn acts as a stand-alone wireless access point using the Raspberry Pi's on-board Wi-Fi. If you plug in ethernet, it can route packets, but DNS forwarding seems broken. Some of the participants will have to be online and available during the workshops, so I wanted to make sure the lab has full Internet access. Additionally, it helps when folks can look up information about vulnerabilities while learning new concepts. I won't always be able to rely on on-site ethernet to provide Internet access to participants, so I decided to set up my MiFi 8800L hotspot as an Internet gateway on RasPwn, and I had to make sure DNS worked.

Hotspot setup:
When you plug in most WiFi hotspots over USB, some will only charge the internal battery, while others will immediately show up as a network device. Some also show up as a "virtual USB drive" with drivers and software. The Inseego MiFi-8800L touch-screen model prompts you when you plug it in, and has an option to serve Internet via USB only or USB+WiFi.

If you use the Web UI, you can set this option as the default. There's no way to set it up from the touch-screen interface. All other Inseego (and their previous brand, Novatel) hotspots I've used can be set up to provide USB Internet access by default, using the web admin portal. See owners' manual for details on accessing the admin portal. It'll probably vary widely by model. Example from my 8800L:

RasPwn setup:

• Download the RasPwn software and follow the install instructions on the download page. If you've messed with Raspberry Pi distributions before, this should be pretty self-explanatory.
• Place the card into a Raspberry Pi 3 and power it up. You won't need a screen or keyboard for anything. I did have to power-cycle the Raspberry Pi after the first boot for the WiFi network to show up. You may have to do the same.  

• When RasPwn boots up, you'll see a new WiFi network called RasPwnOS show up. Connect to it. The default WiFi password is In53cur3! 
  
• SSH to 192.168.99.1. The username is pi and the password is pwnme!
• ssh pi@192.168.99.1
• Set up eth1 (for the hotspot's USB interface)
• edit /etc/network/interfaces with vi or nano
• insert the two lines below, preferably after "eth0" is specified:
  allow-hotplug eth1
  iface eth1 inet dhcp
• Save the file
• Change the IP masquerading rules for iptables to use eth1
• edit /etc/iptables.up.rules with vi or nano
• change the MASQUERADE rule from
  -A POSTROUTING -o eth0 -j MASQUERADE
  to
  -A POSTROUTING -o eth1 -j MASQUERADE
• save the file

•  Set up the DHCP server to issue an external backup resolver
• edit /etc/udhcpd.conf with vi or nano
• change the "opt dns" line from
  opt     dns     192.168.99.1 192.168.99.10
  to
  opt     dns     192.168.99.1 8.8.8.8

(Note: the DNS stuff is kind of hacky. You could configure the on-board bind9 DNS server to resolve recursively, but it's more complicated and this works just fine)

• Reboot RasPwn and test Internet connectivity.
• sudo reboot
• Close your SSH window
• Wait a minute or so
• Reconnect to the RasPwnOS wifi network
• Try browsing the internet. If it doesn't work, make sure the HotSpot is showing a USB connection. You may need to unplug it and plug it back in, or unplug the hotspot, reboot RasPwn again, and plug the hotspot in after RasPwn boots up all the way. 

Okay, so let's hack something!

• Go to playground.raspwn.org from your RasPwn WiFi connection 
• Pick an app and start hacking!

The first thing in the playground is the OWASP Bricks practice application. It's intentionally vulnerable and designed to be increasingly complex with each challenge building on what you learned with the previous ones.

Some of the exercises will require an intercepting proxy such as BurpSuite, Charles Proxy, or OWASP ZAP, but the first login page can be hacked with just a browser. I actually didn't read any documentation for Bricks, and had never played with it before setting up RasPwn. My first login attempt was "admin" with a password of "admin" and it logged me in.

It wasn't until I saw the SQL in the footer that I knew this was supposed to be an SQL Injection challenge.Whoops. Okay, let's try this again with foo and a password of bar.

Okay, so that's what "access denied" looks like. Now let's throw some SQL injection into the username field. Here, I used a username of "foo ' OR 1=1 -- " (note the space after the -- comment, that's needed for MySQL and maybe other databases to acknowledge a comment).

And we've successfully used SQL Injection to hack the first Bricks challenge.

Happy hacking, friends!

Small TFT displays for Kali on the Raspberry Pi

Earlier this week, I saw this hot tip from Hack A Day with regards to a high-performance driver for SPI-driven displays on the Pi. That article was published just as I had been digging into getting my Adafruit 3.5" PiTFT display working under Kali so I can run FruityWiFi and other tools with a super-portable kit.

I've had the PiTFT working under Raspbian for years, but Kali isn't Raspbian, and I remember that getting it working the way I wanted, even with the Adafruit helper tool, was somewhat of an ordeal.

Although a number of folks (e.g. re4son) have published unofficial Kali images for the Pi, some of which claim to work with various add-on displays, I tried and a few and failed to get them to work properly, if at all, even without the display. I started with a fresh official Kali Linux 2018.3 RaspberryPi 2 and 3 image.

The fbcp-ili9341 driver doesn't work out-of-the-box on Kali, either, but getting it up and running wasn't too hard. It doesn't support touch input yet, but for me, Kali requires at least a keyboard, and my trusty Logitech K400r (affiliate link) is always nearby. One thing I like about framebuffer copy (fbcp) is that you can have the Pi plugged into HDMI (or not...) and the video is mirrored to the TFT, but needless to say, you'll have to start with the Pi plugged into an external monitor until you get the TFT working.
 
To get the driver to compile on Kali, I had to download libbcm_host.so, libvchiq_arm.so and libvcos.so from the opt/vc/lib directory of the RaspberryPi Git repository (or you could copy them from a running raspbian host or SD card).

I put the library files in /opt/vc/lib (I had to create this directory) and then added it to the libary path by creating a file called /etc/ld.so.conf.d/vc.conf :
#vc libs
/opt/vc/lib

run ldconfig to reload the library cache.

I'll be going through the steps specific to the Adafruit PiTFT 3.5, however it looks like a lot of various, generic displays have been tested to work, as long as you pass the right options to cmake when you build it. The Readme in the repository has a lot of helpful tips on cmake options, but the basic "get it compiled" instructions are pretty simple:

For the Adafruit PiTFT 3.5 display, this was the magic sauce for the cmake command, though you may wish to mess with the Clock Divisor timing:

cmake -DADAFRUIT_HX8357D_PITFT=ON -DSPI_BUS_CLOCK_DIVISOR=30 .. 

Before I ran "make -j" per the above, I edited config.h to make some tweaks, uncommenting two options to get the orientation of the display the way I wanted it (so the Raspberry Pi power plug sticks out of the top when looking at the screen upright) and to fill more of the display:

#define DISPLAY_ROTATE_180_DEGREES 
#define DISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING 

Once I got it running nicely, I copied the binary to /usr/local/bin/fbcp (because I can't remember "fbcp-ili9341")

Next, I edited /boot/config.txt and experimented with the various video modes to give me a display that was both legible on a tiny screen, and filled as much of the display as possible. I ended up with a 480p 16:9 mode that, combined with the BREAK_ASPECT_RATIO fbcp build config, looks about as good as I can get it on the display. You'll have to tinker with these options to find what works best on yours. I added this to the end of /boot/config.txt:

hdmi_group=1 
hdmi_mode=3 

If you're cool with running full brightness, you can skip this next part. If you want variable brightness on the backlight, we have to configure GPIO. This display uses GPIO Pin 18 for the backlight LEDs. Other TFTs might not support PWM brightness control, or may use a different pin than 18 for it. By default, the display is on 100% full brightness, but if you tweak the GPIO configuration in the bootloader, you can use PWM to modulate the brightness. I added the following line to /boot/config.txt:

dtoverlay=pwm,pin=18,func=2 

This change will kill the power to the backlight at boot (as the PWM mode will default to no power output) so you'll need to initialize and power-up the GPIO at boot if you want the display to be usable. To do this, I created a "rc.local" file in /etc (which systemd will run at boot) to launch the fbcp driver, initialize the GPIO, and set the display to 50% brightness. I'm running a really high frequency on the GPIO because a lower frequencies created a very audible high-pitch whine, and very low values (e.g. periods of 255 to 10000) were not giving any kind of granularity to the backlight brightness. /etc/rc.local:

#!/bin/bash 
/usr/local/bin/fbcp& 
echo 0 > /sys/class/pwm/pwmchip0/export 
echo 10000000 > /sys/class/pwm/pwm0/period 
echo 5000000 > /sys/class/pwm/pwm0/duty_cycle 
echo 1 > /sys/class/pwm/pwm0/enable 

Make sure it's executable:
chmod 755 /etc/rc.local

I opted to enable automatic login (as root) on this since it's basically a plug-in-and-go appliance. I followed this quick guide.

Reboot to test it out. You should see a white screen (or whatever was on the screen before rebooting) for a few seconds, then the backlight should go out until rc.local is executed right before it goes into GUI mode.

Finally, I created a "backlight.sh" script that handles setting the brightness. You'll need to make this executable, too. Syntax is basically "./brightness.sh (percentage)" where 0 is off, 1 is very dim, and 100 is full brightness.

#!/bin/bash
if [ -n $1 ]
    then
    echo ${1}00000 > /sys/class/pwm/pwm0/duty_cycle
fi

NetBSD 7.0 working on the Raspberry Pi Zero

The NetBSD Wiki has a nice page about Raspberry Pi support, including instructions for finding a nightly snapshot image for Raspberry Pi SBCs.

Trying to boot the latest snapshot (201512311300Z) on my Pi Zero resulted in 8 flashes of the OK/ACT LED (bootcode.bin and/or start.elf problems, according to the documentation). This image boots fine on my Pi B+ and Pi 2.

I over-wrote bootcode.bin, start.elf and start_cd.elf on the freshly imaged NetBSD SD card from the version on my Pi Zero Lapdock (installed from a recent Arch Linux image. NetBSD 7 now boots on the Raspberry Pi Zero. I don't know if these are exactly the correct files, but I suspect they likely require updating in the NetBSD base image.

I've included MD5 sums of the files for your convenience: From the NetBSD Image: 
MD5 (bootcode.bin) = 9a4ad6a12ad7dc1aae279888c25d2252 
MD5 (start.elf) = a2c4b9ea3ae986f88ea01e05bef46904 
MD5 (start_cd.elf) = 85924312c9b51d1ef5b7ca301bb18d54

Files I copied over from Arch Linux that make it bootable: 
MD5 (bootcode.bin) = 6cc6560c0178c10928d14b8768969dab 
MD5 (start.elf) = f5b2a422d863efe5d47b1ac291ccaa3a 
MD5 (start_cd.elf) = f0dfc1462c5d9b003b64428fd52406ed

(I posted a variant of this as a comment on the NetBSD wiki. It hasn't shown up yet. It likely requires approval)

Raspberry Pi Zero inside a Lapdock 100

A lot of folks have used the Motorola Lapdock as a portable complement to the Raspberry Pi. It usually ends up as a big mess of cables. My Lapdock was actually used a lot with my last phone, as it was intended to. Occasionally, people would ask me if I was using it for a Pi. My response was "If I can figure out how to fit it inside, I'll try." I always figured it would involve de-soldering all the GPIO headers, network and USB jacks to make it thin enough to fit, then a bunch of soldering to hard-wire everything together.

With the announcement of the Raspberry Pi Zero, I knew it was finally time.

I did a little bit of recon inside the Lapdock case. Plenty of room for a Raspberry Pi Zero and some cables.

Opening up the LapDock isn't too hard. Start by prying the keyboard loose from the top, with a small flat-blade screwdriver or a spudger. Underneath, you will find a single ribbon cable for the keyboard, and a number of screws. Remove the keyboard and all visible screws. The only thing left holding the case together after that are the four screws on the bottom case, one at each corner.

Once I saw the layout inside, my plan was to place some pigtail connectors inside the chamber that the dock connector rests in when not in use. The speaker on the left bottom corner is kind of in the way.

I ordered two cables from Amazon:
Micro HDMI Female to Mini-HDMI Male
USB On-The-Go Extension

I tested everything outside the lapdock first.

Miraculously, both cables worked great. I'd read many horror stories of HDMI cables and adapters that didn't work well with the Raspberry Pi. Not bad for 12 bucks.

Inside, I got to work. First things first, remove the speaker, held in by two screws. Remove the battery, too. It sits loose in the case and is easily unplugged.

At this point, it was obvious to me that I couldn't put the pigtails inside the case where I had planned. There's just not enough room under the speaker. I took the top case apart a little further by removing the screws marked below.

 

I cut away a little piece of plastic under the speaker to open up some space near where the dock cable rests.

Then, I pried apart the upper part of the dock on one side, giving me enough room to make a cross-shaped hole in the rubber dock membrane by making two slices with a knife.

I'll have to run the pigtails through this corner of the phone dock. I routed the cables through the maze of plastic and shoved them through this hole.

I had to make sure the plugs were oriented properly for a good fit with the dock connector.

To make room for the Pi, I took a knife blade to some of the plastic structures inside the case. A tab (not shown) on the lower case lid also needed to be trimmed.

The final part before reassembly was trying to find a good way to route the cables so that the Lapdock could be reassembled nicely. I held the Raspberry Pi Zero down with some double-sided foam mounting tape once I had everything in position. This tape also insulates Pi from the metallic coating on the inside of the Lapdock's case, so don't skimp on it.

Once everything was buttoned back up, I plugged the dock connector into the pigtails again and powered the dock up.

The end result is a nice, self-contained computer powered by the Raspberry Pi Zero, but the dock is still usable for other devices.



Update: 2015-01-24

Frequently, you have to use the reset button on the bottom of the lapdock to get it to boot proplerly, and I wanted to be able to reset the dock with my pinkie finger. Also, I wanted a way to easily swap out MicroSD cards. To fix these two issues, I used a stepped drill bit to enlarge the reset pinhole and to give me access to the Pi Zero's card slot.

PiTether: Mobile phone to ethernet bridge

Introduction

If you saw me at DefCon this year, you probably saw me using my HP Jornada. There was also a pretty good chance that you saw me getting it online in strange ways...

HACK THE PLANET! (Or just dial up a BBS...)

Since there aren't payphones everywhere, though, I built something interesting back in May, preparing for DefCon. It's a very simple Raspberry Pi ethernet bridge. I did this mostly to avoid using the open WiFi at DefCon, understanding that 3G/4G shenanigans are happening, but with a higher barrier to entry than the 802.11a/b/g/n/ac mess.

Yes, that's a Raspberry Pi Model B inside a case made of LEGO bricks.

Setting up Arch Linux

Being no stranger to building embedded systems, I decided to go with a bare-bones Arch Linux ARM install on a 2GB SD card. You could likely run with an even smaller card if you wanted to. The installation instructions are pretty straight-forward if you're familiar with the command line.

Once you have Arch Linux up and running on the Pi, I recommend changing the default passwords (alarm/alarm, root/root) and then doing a system update to get the latest packages from base. Simply connect the Pi to the Internet through its ethernet port, then run "pacman -Syyu" as root.

Configuring the network

The 3 interfaces we worry about are eth0, usb0 and br0. The first two basically work right out of the box:

/etc/systemd/network/eth0.network exists from the default installation, so the ethernet port is already set up for us.

When you activate USB Tethering from Android while plugged in to most modern Linux distros, it shows up as a network device (in this case, usb0) without any extra configuration.

br0 (the bridge interface) needs to be configured. First, we establish a netctl profile for it. Put the following text into a file called /etc/netctl/br0

Description="PiTether USB/Ethernet connection"
Interface=br0
Connection=bridge
BindsToInterfaces=(eth0 usb0)
IP=dhcp
SkipForwardingDelay=yes

Next, create a service file for systemd that calls netctl for the br0 interface. Put these contents in /etc/systemd/system/netctl@br0.service

.include /usr/lib/systemd/system/netctl@.service

[Unit]
Description=PiTether USB/Ethernet connection
BindsTo=sys-subsystem-net-devices-eth0.device
BindsTo=sys-subsystem-net-devices-usb0.device
After=sys-subsystem-net-devices-eth0.device
After=sys-subsystem-net-devices-usb0.device

Run the following command as root to enable the interface during start-up:

netctl enable br0

Reboot the Pi to make sure everything works as planned. To test:

1. Plug in your phone and activate USB Tethering.
2. Plug a device into the ethernet port of the Raspberry Pi
3. Request a DHCP Lease (happens automatically on most devices)
4. Try to browse the web or connect to something over the Internet (ping, ssh, etc)

As a finishing touch, I decided to make the entire filesystem read-only. This makes it so that the device can be safely powered off by simply unplugging it without any risk of corrupting the filesystem. I did this so that I never needed to SSH to it or hook up a console to safely shut it down. Since this is really a single-use project, this works pretty well. For more elaborate embedded-system work, I usually opt for a RAM disk configuration, but that's not needed here.

You can probably do this by sliding the write-protect tab on the SD card (for Pi A and B only) however, I opted to mark both filesystems "ro" in /etc/fstab. Apparently, root (/) is optional in fstab, but I added it by copying the /boot line and slightly altering the device and mountpoint fields. My /etc/fstab looks like this:

#
# /etc/fstab: static file system information
#
# file system   dir     type    options         dump    pass
/dev/mmcblk0p0  /       ext4    defaults,ro     0       0
/dev/mmcblk0p1  /boot   vfat    defaults,ro     0       0

You can give it one more reboot and test after that if you want. If you ever want to change anything in the filesystem, you can temporarily remount it read-write again by using the command "mount -o remount,rw /" while logged in as root. You can use that to remove ",ro" from the fstab options or to occasionally update packages.

Raspberry Pi Zero in a USB Hub (Part 1)

I've had this USB Hub kicking around for a while. I like it because it came with a good power supply and it can handle things like 1-Watt USB Wi-Fi adapters, RTL-SDR receivers and USB-powered hard drives with ease. It's small enough to stash in my backpack.

As powered hubs go, this one isn't anything spectacular.You can probably do something similar if you find the right hub.

This hub's case popped open easily with just a spudger and some fingernails. I took the circuit board out and found a spot to get 5VDC near the power input port. I soldered some wire to a pad, and another wire to ground. I attached these to the +5V and ground rails through the Raspberry Pi Zero's GPIO header (Pins 4 and 6 respectively)

Next, I cut some notches in the plastic case for HDMI and the USB OTG cable. I'd like to eventually wire the USB directly to the hub's board, but that'll be for part 2. For now, I need a hole in the case for USB. Everything lines up nicely.

I used electrical tape to insulate the bottom of the Pi, and the top of the USB ports inside.

Some 3M double-sided mounting tape holds everything in place. Sorry for the blurry shot. I didn't review some of these photos until everything was stuck back together.

With the cover snapped on, it almost looks like a normal USB hub. In fact, as pictured, it would still work like one, with a Raspberry Pi whirring away silently inside, hooked up to nothing other than power (which it can also get from USB without the DC power supply.)

I have a Logitech wireless keyboard/mouse and a USB WiFi adapter plugged in. This is pretty much the bare minimum to get a Pi onto the Internet and usable. 

Since I haven't gotten USB hooked up inside the case (I'll need some fine wire, a really good SMD soldering iron and a steady hand to attempt that), I still have to hook the Pi's USB OTG port on the front to the USB port on the back of the hub.

Not terribly elegant, but it works.

That's pretty much all there is to it.  Plug in the Mini-HDMI cable and the power supply and watch it go. You've got a computer that's better than anything I had in the early 2000s in something roughly the size of a pack of gum, and you'll have a decent number of USB ports to work with, too!

Raspberry Pi random host generator

Say you have a really watchful network/systems administrator that keeps a close eye on new devices being joined to the network...

You know where this is going. It's April 1st.

Toss this into /home/pi, then make it executable.

#!/bin/sh
while true
do
  mac=`echo -n 00:03:BA; dd bs=1 count=3 if=/dev/urandom 2>/dev/null | hexdump -v -e '/1 ":%02X"'`
  newhost=`dd if=/dev/urandom bs=35 count=1 2>/dev/null | tr -dc "a-z"`
  echo $mac $newhost
  ifconfig eth0 down
  pkill dhclient
  hostname $newhost
  ifconfig eth0 hw ether $mac
  rm /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_dsa_key
  ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa -P ''
  ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa -P ''
  ifconfig eth0 up
  dhclient eth0
  ip addr show eth0 | grep "inet "
  echo "Sleeping..."
  sleep 60
done

You can add the below line before "exit 0" line at the end of /etc/rc.local on Raspbian to make it start up at boot.  You have a random host generator that spawns a new MAC Address, random host name and new SSH keys every minute or so.

nohup /home/pi/mac.sh >> /tmp/mac.out&

A few notes:

• This will totally hose all of your SSH host keys on the pi.  Make backups of them if they're important to you.
• I chose an OUI (00:30:BA) that I knew would not match anything else on the target network. You may wish to do some research and change the hard-coded OUI prefix in the code above.
• The interface fluxing will also make remote management troublesome unless you have a wireless adapter that's on a more stable network, but this can betray you, as the host keys keep changing to match the wired interfaces. 
• I took the additional step of leaving the Pi powered on for a few minutes before attaching the ethernet cable, so that it wouldn't ever show up on the network with a Raspberry Pi MAC address, since it had time to generate a new fake address before I hooked it in.
• There are some very simple ways to defend against something like this.
• It goes without saying, but pranks at work can lead to disciplinary action.

Also, thanks to the target of this April Fool's day prank for giving me a few extra ideas (included here, but not in the original implementation) after catching me in the act.