This is exactly the kind of project that’s easy to take for granted until the day you need a specific BIOS and every download you find is dead or unverifiable. Checking against emulator source rather than trusting whatever’s floating around is the right call, that’s usually where these collections go wrong.

Bookmarked for when my Batocera box inevitably needs a re-flash. Do you have a cadence for pulling in new releases as RetroArch etc. cut new versions, or is this more of an as-needed refresh?

Do not buy another consumer-grade extender for that link, it’s the wrong tool for a fixed 120ft point-to-point hop. What you actually want is a proper wireless bridge pair, Ubiquiti’s airMAX line (NanoStation or PowerBeam) or MikroTik’s wAP series will both wildly outperform any off-the-shelf extender at that range, especially through wood with no metal in the way.

Point one unit out from the house, one at the cottage, run them in bridge/station mode instead of repeater mode, and you’ll get close to wired speeds since it’s a dedicated directional link instead of a shared radio also serving normal WiFi clients. Should comfortably handle the camera at full resolution.

Costs more than a $40 extender, but a used NanoStation pair runs cheaper than trenching, and attic mounting like you’re already planning is exactly the install these are made for.

Almost certainly leftover reference-firmware laziness, not an actual requirement. A lot of cheap WiFi-radio modules ship with a default setup-AP mode meant for initial onboarding via a companion app, and a lot of OEMs never gate it behind a real first-boot-only flag, so it just stays broadcasting forever.

Since you can’t disable it or change the MAC, containment beats fixing it: block that MAC at your AP/controller so it can’t associate with anything, or isolate it if your AP supports MAC-based assignment. Doesn’t stop it broadcasting, but stops it being useful to anything nearby.

If you’re on anything with a reasonably current systemd (248+, so basically any Debian 12/Fedora/Arch box), FIDO2 via systemd-cryptenroll is the one I’d reach for first, no extra daemons, actively maintained since it’s just systemd itself.

HMAC-SHA1 (yubikey-luks project) is the most battle-tested of the three, but it’s a third-party keyscript hook with spottier maintenance over the years. The SHA1 part isn’t actually a security weakness here since it’s HMAC challenge-response, not collision resistance, so don’t let the algorithm name scare you off it.

OpenPGP-on-Nitrokey is the heaviest of the three (needs gpg/scdaemon alive in initramfs), but worth it if you’re already using the OpenPGP applet for SSH auth or email signing.

I run FIDO2 with a TPM2 enrollment as fallback so a lost key doesn’t lock me out entirely.

Pangolin’s default docker-compose ships its own Traefik container, and that’s almost always what’s actually fighting your existing one, not a config typo on your end. Two ways out of it that I’ve seen work:

• Comment out the traefik service in Pangolin’s compose file entirely and let your existing traefik instance handle routing via labels. Pangolin’s docs have a section for using an existing reverse proxy that walks through pointing your own traefik at Gerbil’s exposed port instead of the bundled one.
• Or the reverse: let Pangolin’s traefik own ports 80/443 and demote your main one to a different port/internal-only role if it’s not doing much else.

First option is cleaner if your main traefik is already handling other services and you don’t want two separate ACME/cert setups running side by side.