v2.5.0 — MAC randomization

Wi-Fi MAC randomization is now part of a full install

Panoptes shipped three tools that read or undo MAC randomization — netcheck reports it, netmaster flags it as a captive-portal blocker, wifi-recover.sh disables it — but nothing that turned it on. The enabler was never a script, just a NetworkManager drop-in, and it had been left behind in the predecessor deploy kit.

share/nm/mac-randomization.conf is now installed to /etc/NetworkManager/conf.d/ by sudo ./install.sh, setting wifi.scan-rand-mac-address=yes and wifi.cloned-mac-address=random so an access point cannot recognize your machine across visits. Skip it with --no-mac-random. This is the only file Panoptes places outside a bin directory.

NetworkManager is not restarted. A restart tears down every connection mid-install, and on a machine whose default route belongs to a VPN's adopted tunnel that can strand the route table. Randomization takes effect on your next reboot, or immediately with sudo systemctl restart NetworkManager.

The installer declines on drivers that cannot cope

wl, b43, b43legacy and brcmsmac — Intel Macs and older Broadcom laptops — take the MAC from the chip. NetworkManager clones it, association fails, and the machine is left with no Wi-Fi at all: the exact hole wifi-recover.sh exists to dig out of. On a match the installer names the interface and driver, explains why, writes nothing, and prints the manual override.

The test is the driver rather than the vendor, so brcmfmac Broadcom parts — Apple Silicon BCM4377/4387, and the SDIO parts on single-board machines — are not skipped. They clone correctly.

Uninstall

uninstall.sh removes the drop-in only when it is still byte-for-byte the file Panoptes shipped; an edited or pre-existing file is left alone and reported. A config displaced at install time is saved as mac-randomization.conf.pre-panoptes — deliberately not a .conf suffix, since NetworkManager reads only *.conf from conf.d — and is put back on uninstall.

New README section: captive portals

Hotel, airport and café Wi-Fi is where a hardened stack most convincingly looks broken, and WARP is the layer that does it: the tunnel carries your traffic past the portal, so the portal never gets a request to redirect and the login page simply never appears. You get a dead connection, not a redirect.

The new section tabulates each layer — WARP, DNS-over-TLS, MAC randomization, ipv4.ignore-auto-dns, NM connectivity checking — against the reason the portal fails, then gives the order that works:

sudo netmaster portal    # WARP down, plain DNS, stable MAC, accept their DNS
# log in at the gateway it prints, and confirm you are actually online
sudo netmaster restore

Reconnect WARP only after the portal has authorised you. Bringing the tunnel up first puts you straight back where you started.

Also in this release

• SECURITY.md covers the drop-in. In scope: the driver guard failing to decline, the file being written despite --no-mac-random or by a partial install, a displaced config saved somewhere conf.d still parses, and netcheck reporting MAC privacy the adapter is not applying. Out of scope: what a randomized MAC does not hide, and captive portals breaking, which is documented behaviour.
• Fixed: uninstall.sh never removed warp-setup.sh. It was added to install.sh's system tools without being added to the uninstaller's, so it survived a sudo ./uninstall.sh in /usr/local/bin.

Full changelog: https://github.com/doug445/Panoptes/blob/main/CHANGELOG.md