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.

True fully-open WiFi camera hardware is basically nonexistent. Closest you’ll get is OpenIPC (openipc.org), open source firmware for the SoCs a bunch of budget cameras use, but it’s a compatibility gamble per exact model, not plug-and-play.

More realistic path for a Tapo-style setup: keep the camera on an isolated VLAN with zero internet route (kills the cloud phone-home even on stock firmware), point it at a self-hosted NVR like Frigate or Shinobi over local RTSP/ONVIF, and never touch the TP-Link app or cloud account. Doesn’t make the firmware itself open, but it makes the actual footage 100% local, which is usually the part people actually care about.

If you specifically want reflashable open firmware, OpenIPC’s supported-devices list is worth checking before buying anything new.

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.