The PirateBox Pi Papoose

I have this project that has stalled out, for now…. I always have a dozen projects that I’m interested in working on, and, of course always a few dozen things I should be doing instead.  Maybe someone can help with this one, or run with it. If not, I’m sure I’ll get back to it eventually, but the nest few months are going to be crazy for me.

It’s about PirateBox, and Raspberry Pi, and a notebook computer, so you’ll need to know about PirateBox and maybe have some enthusiasm for the idea of un-monitored, portable, private local networks, and it will help to have basic familiarity with the Raspberry Pi, though I’m guessing that’s less important.

The basic idea is that you’ll be able to walk into a coffeehouse or take a table on the sidewalk somewhere, pull  out a notebook computer with some electronic bits stuck somehow to the back of the lid (very cyberpunk aesthetic, sort of like a DeLorean with high-tech stuff stuck on the outside), have PirateBox up and running in the background to entice other folks around to log in and share whatever while you work on the notebook and  on the Internet in the foreground, but you’re still able to connect to the  PirateBox, monitor and control things there from the notebook.

The PirateBox hardware will be capable of being turned on and off and working independently of the notebook computer on battery power if desired, but it will also use the notebook computer’s USB port for power and for recharging its own battery.

The notebook computer can be used normally for any purpose while the PirateBox is in operation- importantly, the PirateBox is not using or controlling the Wifi capabilities of the notebook, so the notebook can be used for normal browsing or other connected tasks while PirateBox is in operation.

I expect there would be a switch capable of controlling the power for the PirateBox and initiating an intelligent shutdown. What would be REALLY useful (this is from experience) is to have status indicators, at least an LED or maybe a counter of some kind showing that one or more people are connected to the PirateBox, so you can avoid just cutting them off in mid-session by turning it off or leaving, unaware that they were logged on.

_____________

Once upon a time I set up an older Raspberry Pi to run Piratebox and enclosed it, along with big rechargeable USB battery packs, some switches, a radio-controlled remote on/off switch, USB Wifi Adapter with a detachable antenna, all enclosed in a very sturdy and waterproof Pelican case about the size that is used for a professional camera. This was when the RPi 2 was current, and the power requirements were significant, it would only run for about ten hours before the power pack was drained. I rotated them to maximize uptime, but had to do that at least twice in 24 hours.

It worked, but several deficiencies came to light while using it. One of the most glaring was that there was no easy way to tell when somebody was logged on. I frequently needed to shut it down to work on something or change batteries, whatever, and didn’t really want to rudely cut off anyone right in the middle of doing things, but there was basically no way to tell. That really needs to be fixed. I understand that there is at least the foundation of a way to tell how many are logged on to PirateBox now at the OS level.

If I had full time to do this today, I’d use :

Raspberry Pi Zero W or Zero W H (I’ll need the GPIO for indicators), I have these on-hand, and basic cases for them.

Adafruit PowerBoost 1000c, which is a 5v power supply and lithium-ion battery charger.There are lighter, smaller and cheaper power controllers out there, but in this case I’d rather use this one. The charger logic is pretty sophisticated, rather than just running the device off of the cell whether it’s being charged or not, it much more efficiently will power the device directly and use whatever capacity is left over to recharge the cell. I have one on-hand, it cost about $20.

2500 mAh LiPo cell. I’ll need to acquire one.

Power Controller: Basically a fancy on-off switch. One of the weaknesses of the Raspberry Pis is that the default power-on procedure is to plug it into a power source. The default power-off procedure is to manually shut down the operating system, whereupon the board goes into a “halt” state which consumes little power, but not zero power, and zero would be preferable for running off of a battery. Perhaps even more importantly, the default way to start a Raspberry Pi up again is to unplug it from its power source and plug it back in, so the power needs to be cut to the board anyway at some point to turn it back on. I have found a couple of pretty intelligent power controllers for the Raspberry Pi, both are adequate, both have drawbacks.

An enclosure or enclosures for the gear: Preferably sturdy, preferably water-resistant, and it pretty much has to be transparent or have a transparent lid. A lot of the components have LED indicators, with reason. I don’t want to have to take it apart just to have an idea what’s going on in there. There are lots of waterproof/weatherproof enclosures available in various sizes, but the The immediate problem is vast majority of them are too deep to conveniently piggyback on a notebook computer. Finding one shallow enough and otherwise large enough may not be possible in the short run, I may have to mount more than one small enclosure to house everything that’s needed and wire them together. I’ll need to acquire these.

Miscellaneous cables and connectors, I have tons of this stuff.

So, here’s how far I got… I pulled out a RPi Zero W, installed Piratebox, configured it to work as an “Ethernet gadget” over USB so that I could SSH into the PirateBox from the notebook, and it worked, sort-of. Obviously there’s a lot yet to be done, the enclosures, power controller, hook up the power supply and power controller, rig switches and indicators, but I don’t see any of that really being a problem.

The real snag I hit is in networking software, which is not my forte, to put it mildly. I was able to SSH from the notebook into the Raspberry Pi just fine when PirateBox is not running, so that much works with no observed problems. When PirateBox is running, though, I can only SSH into the Raspberry  Pi when a browser on the notebook is actually logged onto PirateBox. This is workable, but just barely, it turns connecting with the PirateBox into a multi-step operation, and means that there is no way to work on/with the PireateBox if you also have a browser connected to the web.

I’m guessing that this is simply a subnet conflict. The techniques for enabling SSH to a Raspberry Pi over USB don’t seem to have anticipated the Raspberry Pi  effectively operating as a Wifi router (for some bizarre reason) on a different subnet than the machine you’re connecting from. There must be techniques to handle the subnet for the Wifi and USB-as-Ethernet separately, but I’m not even sure whether I need to do this on the notebook or the Raspberry Pi or if either would work. The SSH connection is of course originating from the notebook, but it would be preferable to solve the problem at the RPi, since the changes to enable the USB to operate as an Ethernet connection have been made there anyway, and this would make the Raspberry Pi/PirateBox much easier to attach and control from any computer.

The fact that the fix for this is not easy to find may be at least partly deliberate. What I’m contemplating here comes very close to violating the spirit and intention of PirateBox, of creating a gateway to connect it to the Internet. Close. That is not in fact what I want to do… and I suspect that either fixing the problem from my point of view or actually creating such a connection would be very trivial anyway if my networking skills were not so weak.

I’ve done searches on a solution for this, with leads having to do with either “bonding” a device to an IP address, or forcing a device (in this case the USB port, masquerading as an Ethernet connection) to have more than one IP address simultaneously, but so far the discussions I’ve found of these things assume knowledge that I don’t have, mostly  that you can do the steps they describe as concepts with your specific networking tools.

So, right  now, it’s dead in the water. I’ve got a move pending, and to be honest I do’nt know where this will fall on the priority lists in a new environment even after we’re settled in. Things will be different. Too bad, this still seems do-able and potentially a lot of fun. Any suggestions or comments are more than welcome.

— Robert the Wombat

UPDATE: In order to get moving again with this (probably still after the move) I’m considering just using a “console cable” (USB UART) at least until this is worked out. It’s a simple solution, and since it’s not emulating Ethernet it will eliminate any chance of communication over the cable interfering with the PirateBox router functions. Of course, it’s more hardware, but I have a bunch of UART cables (I even have my 3v and 5v sorted out), they’re cheap, and I have no qualms about cracking open one and desoldering if necessary to get the UART away from the notebook USB jack (where it’s bound to get snagged or bumped and damage something if used that way constantly, reduce weight and bulk (I’ll probably just use the board) and I had figured I’d have to segregate the power from the USB to route through the power controller anyway. It’s sort of brute-forcing the problem, but I hate dealing with the messy network configuration stacks, and it’s pretty much certain to work and be trouble-free. I’ve almost sold myself on the idea.

Looks like the “screen” utility (terminal emulator + window manager) is not installed by default in Manjaro, but it’s in the default repository.

It’s been so long since I used a console cable for a Raspberry Pi (it’s just so convenient to use SSH instead) that it took me a while to think of it.

— Robert the Wombat

UPDATE: You can SSH into an RPI over Bluetooth. I can’t really think of a justification to use this on this project, but it occurred to me that it had to be possible, and it’s cool, so I definitely wanted to save the URL for this article in this post:

Headless Raspberry Pi configuration over Bluetooth

In this case, though, I’ll be wiring the RPi to a USB jack for power/charging anyway, so although it would save including a UART in the mess of circuit boards it would also be wasting half of the functionality of the USB jack I’m commandeering.

Sort of too bad, it’s a cool technique to use. With nice Bluetooth capabilities built into the latest models (no, I don’t know how that antenna works either) I have no doubt that this is going to come in very handy at some time in the future.

Turns out (of course) that the nice folks at Adafruit have a cute little USB UART breakout board for cheap enough to make it not worth tearing apart a cable to get to one, with auto-reset and no drivers required in Linux: https://www.adafruit.com/product/3309

— Robert the Wombat