One Day I'll Change My Name

Project Sentinel: The Beginning

Project Sentinel is an attempt to DIY a Wifi->Ethernet bridge using an affordable SBC computer, to give my family and I our own access point in our incredibly cursed apartment that can piggybank off of our router with its broken 2.4GHz radio to enable us to use our smart lights again, along with having enough horsepower to enable some light microservices.

Rationale

I've been wanting to play with a single-board computer for a while. But I haven't had a good use case for it, and while some offerings from Pine and Orange are decently priced, living on disability support means that the idea of wasting $50 for no reason is a major drag. But recently, an opportunity presented itself.

In the form of our WiZ-based light bulbs deciding they don't want to play ball with our Landlord Special router from 2019 anymore.

We couldn't really find any good reason for this. One day they just refused to sync with our Wi-Fi. Nothing seems to have triggered it. The postulation we found online ranges from dead Wi-Fi radios (unlikely since they all stopped syncing at once) to certificate shenanigans (plausible, but why does a smart light with no hub need SSL?) to a lack of a separate 2.4GHz channel (this is the most likely, since nothing we've been able to do to it seems to present a 2.4GHz band anymore.)

If I didn't live in a Kafkaesque administrative hairpin of a living situation, we could just ask our landlord to replace our router. Unfortunately, we're not actually their tenant; we're subletting, and our roommate is best described as an absentee. We've tried to call and make an account with their portal, to no avail. In an ideal scenario, we'd be able to run an Ethernet cable from the office where the router is to our apartment over the ceiling (there's a drop ceiling where it could run with minimal effort) but... again, we have no way to get in touch with them, and when they find out, we have no way to know how they'd react. (Probably badly!)

Mom was originally considering replacing all of our smart lights. But this would be very expensive, not to mention letting them become E-waste is a damn shame, when this scenario also presents a prime opportunity to Become Ungovernable.

Before I learned about the magic of Tailscale (which may or may not become useful for this, I don't know yet!) what I did to get a decent WLAN setup sans-DHCP was use a third party router, set it up in bridge mode, and tether my desktop PC's Internet connection. This worked great, and WLAN on the internal network was fast, since it has WiFi 6E. Tailscale has largely made this unnecessary for my everyday homelab use, and it's a lot of extra faff on my desk that I didn't want to deal with; as a result it's been unplugged. (It's also got a broken antenna but I don't expect this to be a major issue. It's one of those gamer-y looking things with a whole gaggle of them.)

If I could replicate this setup with a separate device whose software is stable (since I like to mess with my desktop and don't want to break the house's WiFi if (when) I decide to distro-hop!) and can live in the kitchen where I don't have to fiddle with it (except to maybe reset it since let's be real I am probably going to have to do that) and that I can also load up with Home Assistant for tighter integration of our lights with our smart devices, that'd be pretty nice. (Plus it would open up the potential for Activities!)

The way I see it, I have two options for this.

  1. Set up some jank with one of my spare laptops. (I could, but I also want to use those for stuff, plus the power supplies are bulky and those laptops are all aging and I don't know what could go wrong with any of them)

  2. Do that same jank.... but with an SBC!

The advantages of this are myriad:

And that last point is really why I'm bothering to do this at all. I could set up the jank I had before, maybe my mom and her boyfriend could switch to it and get our remote lights back. But I'd be tying myself even tighter to my Debian 12 install which I want to move away from. If I can free myself from having to consider the stability of the bridge in my decisions about my tech life, that would be the best for everyone.

Pretty much the only thing I'd have to do to make this work is set up the software stack, which I've already done in the past; I understand these concepts and components, I just have to apply them.

So here's the plan.

So Here's The Plan

Step 1: Proof of Concept

The SBC I'm eyeballing for this project is the Orange Pi Zero 2W. It's got a quad-core ARM CPU at 1.5GHz, which should be plenty for this project; the bar right now for it to handle packet routing, which is so cheap that our air fryer could do it if it had a network connection. It also comes with up to 4GB of DDR4 RAM, and that's the model that's on sale right now with an expansion hat and USB-C power brick for $70 CAD at the moment. Needless to say, that'll be plenty of headroom, and the USB ports on the extension board mean it could do some basic network-attached storage (although it is USB 2.0, unfortunately.)

If I knew this was going to work gangbusters, I'd splash out for a Raspberry Pi. But at the moment, I'd prefer something that if it all falls apart, I can retool for something later, or just play with, without feeling bad about being out the money.

This is going to be using Linux because that's what I know. So I'm going to need to develop something that I can transfer to an ARM system. I have two options for this.

  1. I could build an image from tabula rasa, perhaps with OpenSUSE's built-in image creation tooling (which would be a good chance to explore another thing I've been wanting to!) or by retooling an existing networking distro like OpenWrt (which I have no idea about and is probably overkill.) The main advantages to this are performance and longevity; SBCs typically run on SD cards, which are I/O bound and have a set lifespan, so the fewer reads/writes I can do to it, the better. The disadvantages are that if I want to add things, I have to deploy changes by hand, and if I break it... well that's a huge drag.

Or,

  1. Docker.

I hardly know her!

I've been learning Docker recently, and while I've been mostly having a good time, I've also run into some problems that are mostly to do with the complexity of the scenario I was working in. A container-based solution would be liberating in the planning phases, and make it possible to tweak the setup with some assurance that it'll work on the board if it works in the planning phases, as long as the image (or images if it comes to that) that I use support ARM.

But while that's all well and good, it also necessarily comes with overhead. And while I could give any running containers access to the host networking and be done with it, the configuration could possibly mean trying to deal with networking between them, which is kinda what's been filtering me. I've heard it said that Docker incurs overhead, and while I'm sure that's true, I also don't know just how true it is.

Containers are, usually, built on Alpine, which is a distro designed to leverage mighty Linux power while also being performant enough to be viable in embedded scenarios, which is indeed what it's usually used for. (It's also a distro I happen to have some experience with, so if it comes down to building a container from scratch, which probably won't be necessary but it could well be, then I already have a leg up.)

I don't know exactly what I'm going to do yet; I'm just keeping the field open. If I do have to build my own Docker container, that could even be beneficial, because I could build an container, and then... just deploy it as an Alpine image on bare metal. That'd be pretty neat!

Step 2: Draw The Rest of the Fucking Owl

Buy the SBC, deploy whatever solution I've concocted onto it, fix it when it inevitably doesn't work the first time, get an extension cable if I need to, and set up the SBC and router wherever it'll live for the next... however long it takes for it to break.

If I seem a little unconfident, that's largely for The Joke™. But there's also a few things I'll have to learn for this project. It's uncharted territory, but it rhymes just well enough with what I have experience with that I'm willing to feel it out.

I'll write more blog posts about Project Sentinel as I work on it, but for now this is here so that I have a rough outline of the project to build something tighter out of.