Author: canutethegreat

  • Patronus dev log 1: a firewall that claimed 100% feature parity on day one

    Patronus dev log 1: a firewall that claimed 100% feature parity on day one

    Part 1 in the Patronus dev log series.

    Backdated. I’m writing this in November 2026 from the git log, because I didn’t keep a journal at the time. It covers the first four days, October 8 to 11, 2025.

    Patronus is a firewall and router OS in Rust, aimed at Gentoo. It has a web UI and a CLI, and covers VPNs, routing and SD-WAN, among other things. Like Horcrux it’s Rust, for memory safety and compile time checks. I’ve used Gentoo since 2006 and I’ve done pentesting.

    Day one

    October 8 has 20 commits. The second one is titled “Patronus Firewall v0.1.0 – Complete Implementation”: 176 files, 51,695 insertions. Its message reads like a product launch:

    - 100% feature parity with pfSense/OPNsense
    - 10-100x faster performance (eBPF/XDP: 40-100 Gbps)
    - Enterprise-grade security (A+ rating, zero unsafe code)
    ...
    - 19 crates, ~45,000 LOC
    - Performance: <100μs latency, 1M+ concurrent connections

    I can’t find any benchmark, any test run or any CI result from that week that measures a single one of those numbers. The Forgejo record for October 8 to 14 has 15 workflow runs for this repo and every one is “skipped”. Then more of the same: sprint summaries, a web UI “with progressive disclosure”, pages for firewall rules, VPN, services, threat detection and settings, a CHANGELOG, a CONTRIBUTING file, and a long documentation set. Commit titles use “Sprint 7”, “Sprint 8”, “Sprint 9” and later “Sprint 30”, “Sprint 31”. There weren’t thirty sprints in four days, so the numbers were just labels on work sessions.

    Days two to four

    On the 9th: login and sessions, WireGuard QR codes for phone setup, WebSockets for live updates, a GitHub Pages site, and an SD-WAN design: per the commits, sites announce themselves with Ed25519 signatures and peer over WireGuard automatically, plus path monitoring and Kubernetes NetworkPolicy enforcement. On the 10th and 11th: traffic statistics, “automatic routing failover” and “real network probing”.

    Design decisions I can actually source

    The repo has a blog draft from October 9, 2025, “Why I Built Patronus”. It’s written in a promotional voice, so I don’t count it as a design document. Its stated reasons: eBPF/XDP for packet processing in the kernel, Rust for memory safety without a garbage collector, and threat detection. It claims a 100x throughput improvement over the traditional path. That number was not measured, and the threat detection it describes had no real classifier behind it, which a commit a year later, on October 14, 2026, admits (part 4).

    My own reason for Rust is memory safety and compile time checks.

    docs/GENTOO-INTEGRATION.md has a “Why Gentoo?” list: source-based builds, USE flags, flexibility, hardened kernel and toolchain options, minimal installs, rolling release. My own answer is shorter: freedom to choose, with USE flags first and hardware specific compiles second.

    State at October 11

    No measurements and no CI run that executed.

    Other parts: Part 2, Part 3, Part 4, Part 5.

  • Always Tired?

    Always Tired?

    I started a new job back in July and it is a job that I enjoy. I get to wear several hats. My official job titles are Principal DevSecOps Engineer and Head of Cybersecurity. That’s my bruce wayne job. Also back in July I was recruited to work for a gov contractor. This is my batman job. I’m the only non-military, non-intelligence guy on the team. It’s kind of funny to listen to them talk during meetings. Heavy military and intel lingo at times. For various reasons I can’t share the name of the company, but I’ve come to refer to them as the Secret Squirrel Society and I work on the Secret Squirrel Project. I’m sure some of them would be pissed if they knew that, but I think it’s funny and mean it in a fun-spirited way, not in a negative way. anyway.. I can’t say what the project is or involves. I went from junior team member assisting the lead dev as a favor to one of the founders to being the led dev in about 2 months. I’ve rewritten the backend api from scratch and I wrote a custom ui (actually I’ve written 4 completely separate ui’s from scratch – the other 3 are abandoned now in favor of my current one.) Now I have a tiny glimpse into understanding why bruce wayne stopped being batman after working two full-time jobs – not to mention all the damage he did to his body being a superhero!

    *cough*unrelated*cough* go watch the movies eagle eye (2008) and dark knight (2008) if you haven’t seen them already. Some pretty cool things in those movies involving cameras and AI. Just say’n…

  • The Mystery of The Dying Wi-Fi

    The Mystery of The Dying Wi-Fi

    I recently migrated from a 802.11b/g/n mesh network with a base and two satellites to two standalone 802.11a/b/g/n/ac/ax access points. The reason for going from mesh to a two separate standalone APs was due in part to housing downsize and separating IoT, guests, and questionable devices from my personal, trusted, devices.

    Shortly after making the migration I started noticing frequent, but random disconnects on the 2.4GHz network on the IoT AP for about half a dozen devices. There are approximately 50 devices connected on this AP in total, so having 6 of them disconnect randomly seemed a bit odd. To make things even more interesting, these 6 devices would not automatically reconnect after they disconnect. Seems like a mystery is brewing, and I love a good mystery!

    I started digging into the mystery by making sure the AP had the latest firmware (it did) and confirmed the configuration settings were correct (they were.) Then I tried to identify anything in common between the 6 devices (they were all TP-Link Kasa smart devices.) I thought maybe one of the Kasa devices were malfunctioning and started taking them offline one at a time. No dice! The problem persisted!

    I continued my investigation trying various other things such as reducing the Wi-Fi protocol to only older ones and a bunch of other things. None of this really made much difference outside of slowing down the disconnect rate of the 6 devices.

    Eventually I decided something else must be going on so I set up logging on the AP and had the logs shipped to a machine on my network that runs rsyslog. I went through the logs and discovered something that was not visible in the APs interface nor in the normal event logs: there was a unknown device attempting to connect about once per second but failing to complete the connection. Looking up the MAC address revealed that is was manufactured by “Tuya Smart Inc.”

    Knowing the manufacturer didn’t really help that much other than tell me it was some sort of “smart” device. The next step was a process of elemination where I went throughout the house unplugging every smart device for a few minutes at a time by either unplugging them, which did not reveal the mystery device, or by turning the breakers off in the electrical box. I eventually narrowed things down to one room.

    Once I began looking at what was present and plugged in, I realized there was a “smart” thermometer on the wall in this room. As it turns out, this thing has Wi-Fi, and was not connecting correctly. After removing the power (AC and batteries) the constant connection attempts on the AP completely stopped. The reason this went unnoticed for months was because I do not use the app associated with this “smart” thermometer, but my spouse occasionally does. Apparently she hadn’t used it for a few months to notice it wasn’t working any longer…

    I ended up doing a factory reset on the “smart” thermometer, reconfigured it, and it has been behaving fine since (a few years now).

    Mystery solved!