[vpetersson-bot]

Anthias dropped its captive portal in 2026.04 ("chore: drop wifi-connect service end-to-end"): it was pinned to balena-os/wifi-connect v4.11.1, which had silently shipped no ARMv6 binary since v4.4.6, and the host wrapper's set -e-vs-$? bug made the portal branch unreachable for three years. nmcli / nmtui has been the only path since — fine for an operator with SSH, no help at all for a screen that has never been on a network.

Screenly-Labs/wifi-connect is the ground-up replacement, pinned here at v2026.10.13. This wires it in end-to-end, including the two parts the old integration never had: deciding when a screen should be offered setup at all, and getting the access point's passphrase to the person standing in front of it.

How it runs

• anthias-wifi-connect in docker-compose.yml.tmpl, on upstream's multi-arch image pinned to an exact CalVer release. Nothing is built here.
• Behind a compose profile, so docker compose up -d cannot start it. restart: "no" governs restart-on-exit, not the initial start — without the profile, every upgrade_containers.sh run would start the portal directly and walk straight past the gate, taking a WiFi-connected screen off its network for a 15-minute setup session on every upgrade. upgrade_containers.sh creates the container stopped, by name, so the unit has something to start.
• A systemd service + timer (ansible/roles/network, gated on manage_network) is the only way in: OnBootSec=30s, then OnUnitInactiveSec=5min — inactive-based, so a live 15-minute portal session is never interrupted by the next tick. The service has no [Install] section deliberately; a skipped check must be retried, not be the end of it.
• The portal listens on 8000, not 80 — anthias-server publishes 80:8080 on the host, so binding there fails outright (upstream reports it as PortalUnavailable, and names Anthias in the comment). Phones reach it through DHCP option 114 (RFC 8910, honoured by iOS 14+, Android 11+, macOS, Windows 11) and through the address printed on the setup screen.
• On balena, restart: always is the schedule. The supervisor treats an exited restart: "no" container as finished — it never starts again, not on reboot, only on a new release apply — so a screen installed while online would never offer setup after being moved. restart: always is only affordable because the daemon waits before exiting as of 2026.10.13: five minutes between checks on a healthy screen, six hours after a setup page nobody used. Measured on a wired Pi 5 — without the wait that policy is 4,680 container starts and 19,000 log lines per device per day; with it, 288 starts.
• No gate in front of it on balena. The supervisor starts every service on every boot and release apply, and there is no systemd to hang a condition on — so the daemon decides for itself. That is what 2026.10.11 is for (below); the pin and the absence of a gate there are one decision, and a test stops the balena templates ever pinning below it. Host networking, the io.balena.features.dbus label, resin-data for the state file, restart: "no".

Deciding whether a screen needs setup

As of 2026.10.11 the daemon decides this itself, which is what makes it shippable on a platform with no init system. NetworkManager on every Anthias platform answers ConnectivityCheckAvailable: false — built without it — so its verdict is Unknown forever, and upstream's fallback was "is the radio an associated station". A wired screen never associates, so the honest answer on a healthy wired device was "this needs setup". Upstream now also counts another interface being up (wired, a second radio, a modem), with an allowlist of NetworkManager device types so container veths and bridges cannot be mistaken for a network.

Verified on wired hardware with no gate and no --force, exactly how balena's supervisor starts it: a Pi 5 and a Pi 3 B+ both exit 0 in ~20s with "already online; the portal is not needed", no AP, no state file. The same test against 2026.10.10 raises an access point.

The host-side gate below remains on the Debian path, where it adds the retry cadence and the backoff systemd can own and a short-lived daemon cannot.

The host-side gate on Debian

wifi-connect asks NetworkManager whether the device is online. On every platform Anthias supports, NM answers ConnectivityCheckAvailable: false — it is built without connectivity-check support — so the portal's own gate says "offline" on a device with perfectly good Ethernet. Reproduced two runs out of two on the Pi 5.

So Anthias decides, in an ExecCondition gate, on three grounds — the union of what both predecessors checked, because each alone is wrong in a different direction:

Check	Why	Whose
WiFi already associated	otherwise we tear down working WiFi in order to offer to configure WiFi	balena's iwgetid -r
A wired network is connected	—	—
The internet is reachable	otherwise an Ethernet-only screen never associates and is offered setup forever	Anthias's original wget --spider

The portal's own access point is excluded by profile id: with the portal up, nmcli really does report wlan0:wifi:connected:wifi-connect-portal, which without the exclusion reads as "WiFi is configured".

And a bound on how often it may try. On a site with nothing to join, the gate says "raise" on every tick — 15 minutes of setup page, 5 minutes of content, forever. A screen that played content fine before the upgrade would never play anything again. So: three attempts at the timer's cadence (a first boot is someone standing there with a phone, and three goes covers them walking off to find the password), then one attempt every six hours. Not "give up" — a network can appear with nobody there to notice, and four quiet attempts a day costs a minute in twenty-four of screen time. The count lives in the unit's RuntimeDirectory with Preserve=yes, so a reboot resets it, because power-cycling is what an operator does when they want another go.

The gate's full decision table — including the backoff, its expiry, a corrupt state file, a missing container, and the settle-vs-wait timing — is covered by tests that shell out to the real script with nmcli, curl and docker stubbed.

How the passphrase reaches a user

The access point is WPA2/WPA3 with a passphrase generated per run — a real improvement over the old open portal, but it means the passphrase has to be displayed: it is what gets you onto the network and therefore cannot be served over it.

• wifi-connect writes its join QR to the shared resin-data volume; /hotspot/ renders it full-screen with the SSID, the passphrase and the portal address. Unauth'd like /splash-page (the viewer has no credentials), and it withholds the credentials entirely unless the portal is actually broadcasting.
• The viewer shows that page for as long as setup is running, ahead of the playlist, and leaves on its own when the portal comes down.
• It says passphrase, not password — 802.11's word, and the one printed on the back of every router, which is where someone standing in front of a sign is reading it from. Upstream's portal says the same (Screenly-Labs/wifi-connect#34), so the two halves of one flow no longer use different words for one string.
• --log-passphrase is deliberately not set: a WPA passphrase in journald is worth avoiding when /hotspot is the path an operator actually uses.

A distinct network name per screen

PORTAL_SSID is a prefix as of 2026.10.6; the portal appends four random characters, giving Anthias Setup-G4VV. Unbox five screens in one room with a fixed name and a phone shows one entry for all of them, joins whichever is loudest, and the installer configures a device at random while reading the credentials off another — and since each portal generates its own passphrase, four of the five refuse the passphrase on the screen in front of them. It presents as "the password on the screen doesn't work".

PORTAL_SSID_SUFFIX is deliberately left unset, and a test asserts it stays absent: setting it to 0 opts back into the collision.

The splash label says SSID rather than Network, because the screen sits beside a phone showing a list of SSIDs and the label's job is to tell someone which row to tap.

Branding

The page on the device's display was always Anthias — it is built on the splash design system. The page the user opens on their phone was upstream's blue. Upstream had documented a white-labelling seam for exactly this but never implemented it, so it was implemented upstream (Screenly-Labs/wifi-connect#3) and is consumed here: ansible installs wifi-connect-brand.css and the Anthias mark to /etc/anthias/wifi-connect/, mounted read-only into the portal container.

The stylesheet maps role tokens only — plum-800 canvas under a 4%-white card, fields at paper-6, sun-400 on aubergine for the one button that matters, the splash gradient. Upstream is explicit that the --c-* primitives and the markup are not a public surface, and a test enforces that every custom property in the file is a role and no rule names a component class. WIFI_CONNECT_DEFAULT_THEME=dark pins the scheme, which also removes the portal's theme switcher: the plum canvas is the brand, and which scheme a two-minute setup page uses is not a question to put to someone trying to get a screen online.

Knowing the portal is up

wifi-connect publishes a state file — one atomic JSON write on the volume Anthias already mounts, carrying the SSID actually on the air, the per-run passphrase, the join payload and the portal's address. Anthias reads that; it does not work any of it out.

That contract was added upstream for this (Screenly-Labs/wifi-connect#36, #37), replacing two things this branch used to do:

• Re-parsing credentials out of the QR payload — 70 lines of WIFI: field splitting and unescaping, recovering strings the portal had in hand.
• Probing the portal's HTTP listener — which cannot work from anthias-server. The listener is bound to the gateway scoped to the wireless device so a setup portal can't answer over a customer's wired LAN, and a packet from the Docker bridge is refused: measured again on the Pi 5 at 000 from the container, 200 from the host. It only ever worked because host_agent ran the probe out on the host and published the answer through Redis. The probe, its Redis key and the plumbing are gone.

Three signals now decide whether a setup screen shows, each covering the others' blind spot:

Signal	Catches
The file exists and says portal_active	written once a run commits to raising the AP, removed when it ends — unlike the QR files, which are written before the portal's own online check and so exist on healthy devices too
Its heartbeat is fresh	a portal killed too hard to clean up
The gateway is still on the host	a clock that jumps, and a stale file generally

The heartbeat is there because of a hardware finding: SIGKILL the portal and it removes neither its state file nor its access point — NetworkManager keeps holding the gateway and the radio keeps broadcasting, so every signal outside the file reads as a healthy portal. The grace window is three beats at the interval the file declares, not a constant copied from upstream.

The WiFi-setup poll also stopped waking host_agent on healthy devices: the cheap local read comes first, so the host is only disturbed once something on disk says a portal run is live.

When the portal stands down

ACTIVITY_TIMEOUT is an idle timeout as of 2026.10.10, and was a hard session cap before it — the deadline was computed once and nothing fed it. An installer working through five screens reaches the last one thirteen minutes into its window, joins, starts typing a passphrase, and the access point vanishes. The recovery is worse than the interruption: the next run mints a new passphrase and a new SSID suffix, so their phone will not reconnect and the screen shows credentials that are not the ones they wrote down. On this branch it compounds — every timed-out run counts against the backoff, so three interruptions put the device into its six-hour cool-off with a human standing in front of it.

Captive-portal probe endpoints deliberately do not reset it. A phone that joins the setup network and goes back in a pocket polls /hotspot-detect.html by itself, and counting that would hold a screen in setup mode until someone walked away with the phone — quietly disabling the protection the backoff is built on.

Where the setup address comes from

Nothing here hardcodes 192.168.42.1 any more. --portal-gateway and --portal-interface are the operator's to change, so the portal publishes what it actually used and Anthias reads it:

• portal_is_up is told which address to look for. Under the old constant, a deployment that moved the portal was never detected at all — not a cosmetic problem, a screen that never shows its passphrase.
• strip_portal_gateway gets None when no portal run is live, and then strips nothing. The address is only special while a portal owns it: a customer LAN can be 192.168.42.0/24 and hand a screen .1, and the splash page was dropping that screen's only real address on a network where nothing was wrong.
• DEFAULT_PORTAL_GATEWAY survives only to describe a portal whose state file has not been read. A test parses the module and asserts neither decider references it or the literal.

Also

• The gateway address is stripped from the splash page's "open this on your phone" list. It is a real address on the host while setup runs, but not one anyone should be told to manage the device on.
• upgrade_containers.sh no longer docker rm -fs anthias-wifi-connect — it is a live service again, and the legacy sweep would tear down a portal mid-setup. srly-ose-wifi-connect stays.
• collect_debug.sh collects the container's logs and redacts the passphrase line out of the bundle.
• SuccessExitStatus includes upstream's 6 (TimedOut) — the ordinary end of an unattended session — while a portal that could not bind is now a distinct exit 7 (Screenly-Labs/wifi-connect#24), so a port conflict shows up in systemctl --failed and a timeout does not.
• New docs page, a QA-checklist section, and an updated FAQ answer.
• The 11 SonarCloud findings this branch raised are cleared, including a NOSONAR of mine that read as a suppression directive in its own right.

On network_mode: host

This is the documented exception to CLAUDE.md's rule, and the only one. That rule exists so host-only facts (IPs, MACs, interfaces) are routed through host_agent → Redis instead of punching through bridge isolation to read them, and every Anthias service still obeys it — including, now, this feature's own liveness probe.

This service is not reading a host fact: it is serving DHCP, an L2 broadcast protocol that does not survive Docker's DNAT, and the interface pin that stops it answering leases on the customer's ethernet LAN has nothing to bind to in a bridge namespace. The exception is bounded — nothing Anthias wrote runs in that namespace, and the image is upstream's FROM scratch build.

Verified

Local gates: ruff check + ruff format --check clean; strict mypy . 212 files 0 issues; ansible-lint ansible/ at the production profile; shellcheck clean; systemd-analyze verify clean on the unit, on the board's own systemd; all compose templates render under envsubst and parse via docker compose config; SCSS compiles. pytest -m "not integration": 2504 passed, 3 skipped — 115 of them in tests/test_wifi_connect.py, including tests that pin the compose template to the Python constants, because the port, the QR directory, the version pin, the restart policy and the activity timeout have no compiler between them and a drift there is silent.

On the QA rig, against released images rather than local builds:

• Pi 5 — the full flow: portal up, /brand.css, /brand-logo and /networks answering, CSP and frame/sniffing headers present and the branding surviving them, three APs with two radios each rendering as three rows, a failed join (SsidNotFound) returning 202 → branded connecting page → AP back within ~30s → human-readable error with no profile left behind, QR artifacts landing in WIFI_CONNECT_QR_OUTPUT and Anthias's own parse_qr_payload reading them back, both the PSK ("Passphrase", 8–63 hint) and 802.1X ("Password") arms of the credential field, and the theme pin holding with a phone set to light and to dark.
• Gate behaviour on hardware — online and wired: Skipped due to 'exec-condition' in 0s with the probe never reached. Airgapped wired LAN: same. Container absent: skip with a reason, no failed unit. Portal up: the association check correctly reports "not configured" rather than mistaking the portal's own AP for a configured network. Starting the service while a portal runs does not spawn a second. systemctl enable is refused. State cleared once the device is found online.
• Distinct SSIDs, over the air — a Pi 5 and a Pi 3 B+ raised portals simultaneously from the same prefix and got Anthias Setup-G4VV and Anthias Setup-CMMM, with each board's NetworkManager profile, on-air SSID (iw dev) and QR payload all carrying the same name. The x86 box has a radio and no portal, so it scanned: two separate entries at signal 64 and 40, and zero bare Anthias Setup. The collision shown gone over the air, not inferred from the code.
• The state-file contract, on the Pi 5 — the file wifi-connect writes is 0640 root:root and its SSID matches what iw dev reports on the air; Anthias's own module, copied unmodified into the running anthias-server container, reads the SSID, passphrase, portal URL and QR data URI straight out of it; a graceful stop removes the file and the reader then reports no portal; and SIGKILL leaves the AP up, the gateway held and the file behind — and the screen still goes away, because the beats stopped.
• The idle timeout, on the Pi 5 at ACTIVITY_TIMEOUT=60 so both arms are observable: untouched, still up at 32s and exited 6 (TimedOut) by 87s — the same duration as the old hard cap, which is the point; polled every 25s, still running at 153s; probe traffic only, exited 6 by 88s.
• A relocated portal, on the Pi 5 — run deliberately on 10.77.0.1/wlan0 instead of the default. The state file reports it, the host holds it, the portal answers 200 there, portal_is_up against the old default returns false for that live portal while the declared address returns true, and the splash list drops 10.77.0.1 and keeps 192.168.8.17. A device handed 192.168.42.1 by its own LAN with no portal running keeps that address.
• Unconditional start on wired boards (the balena case) — Pi 5 and Pi 3 B+, no gate, no --force: exit 0, no access point, no state file, "already online; the portal is not needed". Against 2026.10.10, an access point.
• Seeded branding — staged exactly as start_server.sh does: portal 200, /brand.css is text/css carrying #ffe11a, /brand-logo is image/svg+xml and byte-identical to the splash logo, title "Anthias setup". With the branding deleted, the container stays up and still answers 200, logging "could not read --brand-css; serving the portal unbranded" — the race is survivable.
• Every run torn down clean: no access point, no stale NetworkManager profile, stacks back up, rig locks released.

The two upstream blockers noted earlier in this PR are both resolved: ghcr.io/screenly-labs/wifi-connect now pulls anonymously, and the pinned release is complete with its assets published.

🤖 Generated with Claude Code

---

Verified on balenaOS, in QEMU. There is no balenaOS board on the QA rig, so balenaOS 2.83.18 (qemux86-64, NetworkManager 1.28.0, supervisor 12.10.3) was booted under QEMU/KVM to settle the platform-specific unknowns:

• The supervisor reports the setup AP's gateway. With the address on an interface named wlan0, /v1/device went from 10.0.2.15 to 10.0.2.15 192.168.42.1 within ~12s. It filters balena's own bridges (balena0, supervisor0, resin-dns all hold addresses, none appear), and it is a lagging cache — it kept reporting the address after the interface was deleted, which is exactly why the display side treats it as corroboration and the state file as the authority.
• ConnectivityCheckAvailable is false on balenaOS, same as Debian — so the Unknown fallback is the path that runs there too, and 2026.10.11's wired check is precisely what that platform needed. (Connectivity itself still answers 4/FULL, optimistically, which is the trap.)
• supervisor0 is a bridge NetworkManager reports as connected (externally) — concrete proof that upstream's ethernet/wifi/modem allowlist was the right call: a rule counting any connected device would read every balena device as permanently online and never raise a portal at all.
• D-Bus reaches the container with exactly the env and mount from the balena service block: the pinned image exits 3 ("no WiFi device was found" — the VM has no radio) rather than 5, which is what failing to reach NetworkManager looks like.

Not testable that way: raising an actual access point, since the qemux86-64 kernel has no mac80211_hwsim and QEMU emulates no radio. That path is the same code proven on three physical boards; what was balena-specific was the gate and the address plumbing, and both are settled.

Branding now matches on both platforms. The stylesheet and logo were installed host-side by ansible, which does not run on balena — so the portal was Anthias on one platform and upstream's blue on the other. The server container already has both files and already shares a volume with the portal, so it stages them there at startup, the same way start_server.sh already seeds anthias.conf. The host-side install is gone: three ansible tasks, the /etc/anthias/wifi-connect bind mount, and a duplicated logo that a test had to keep byte-identical to the splash page's own file.

The ordering hazard that creates is handled upstream, not papered over here: a portal starting before the server has staged the files used to exit 2, which on balena means no portal until someone reboots. 2026.10.12 warns and serves unbranded instead, so losing that race costs colours, not the portal.

That release also carries a defect found by a colleague running this branch on balenaOS in QEMU: balenaOS has no connectivity check configured, so NetworkManager guesses from the routing table — full with a cable in, limited with it out — and 2026.10.11 believed limited. A wired screen on an isolated LAN has no default route, so it was guessed limited and had an access point raised at it. Verdicts are now trusted only when ConnectivityCheckAvailable says something measured them.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[vpetersson-bot]

Put this through the QA rig end-to-end on real hardware. Summary: the flow works as described, including the two parts that have no precedent in the old integration. Two defects found, neither in this PR's own logic — both are upstream and filed.

What was exercised

Seven boards, all wired, all on Trixie: Pi 5, Pi 4, Pi 3 B+, Pi 3 A+ (32-bit), Pi 2, Pi 1 (armv6), x86.

The gate. Correct on every board that has the unit. Two weeks of uninterrupted history on the Pi 5 and ten days on the Pi 4: every tick skipped with a wired network is connected; skipping the setup portal, no access point ever raised, unit inactive (dead) rather than failed. That is the behaviour the ExecCondition design was for, and it held across ~4,000 activations without a single false positive.

The portal, raised for real. Pi 4, --force, eth0 left up so the box stayed reachable:

"wrote the join QR code"                    path=/data/hotspot/wifi-connect-qr.svg
"found a WiFi device"                       interface=wlan0 driver=brcmfmac
"wrote the portal state file"               path=/data/hotspot/state.json
"scan complete"                             count=3
"access point raised"                       ssid="Anthias Setup-T6XL"
"access point is up; portal is live"

• iw dev wlan0 info → type AP, channel 6. The unique suffix works; Anthias Setup-T6XL, not a bare fixed name.
• Portal answers 200 at http://192.168.42.1:8000/, titled Anthias setup, /networks returning the 3 nearby SSIDs.
• Bound to 192.168.42.1%wlan0:8000 only — not reachable from the wired LAN. Worth stating explicitly since it is a security property nobody has to take on trust.
• eth0 stayed up throughout; no interruption to the device's real network.

The passphrase reaching a person. /hotspot/ rendered the whole thing: "Join the WiFi network below from a phone or laptop… then open http://192.168.42.1:8000/", with SSID, passphrase and QR. The viewer switched to it on its own — WiFi setup portal is up; showing the setup screen until it comes down.

Teardown. SIGTERM, the same signal ExecStop sends: clean exit 0 in 2.4s, AP down, wlan0 back to managed, the wifi-connect-portal profile gone, state.json removed. /hotspot/ immediately went back to "WiFi setup is not running" and withheld the credentials. The viewer resumed playback, then showed the splash with the device address for 60s. Nothing left behind.

32-bit. This is the one I most wanted to check, since the old portal died of a missing ARMv6 binary. The manifest for 2026.10.13 genuinely carries linux/arm/v6 and linux/arm/v7 alongside amd64 and arm64, and both 32-bit boards pulled arm/v7 and ran it:

• Pi 2 (no radio at all): clean no WiFi device was found, exit 0.
• Pi 3 A+: found the device and self-gated correctly — already online; the portal is not needed. The 2026.10.11 wired-detection claim holds on a 32-bit board too.

Two defects, both upstream

1. A soft-blocked WiFi radio is switched on to look at the device, and left on when the portal turns out not to be needed Screenly-Labs/wifi-connect#50 — find_device enables a soft-blocked radio and nothing turns it back off when the run then decides the portal is not needed. Reproduced 2/2 on the Pi 3 A+: radio rfkill-blocked before, enabled and unblocked after, with no AP ever raised. Low impact on the Debian path because the gate usually skips first; on balena, where this PR deliberately runs the daemon unconditionally every 5 minutes, it means an operator who disables WiFi cannot make it stick. Fix in fix(portal): put a radio we switched on back when the portal is not needed Screenly-Labs/wifi-connect#51 with tests.

2. The setup passphrase stays on disk after the portal comes down, while state.json is removed Screenly-Labs/wifi-connect#52 — the session's passphrase stays on disk in /data/hotspot/wifi-connect-qr.txt after teardown, while state.json is correctly removed. Minor (0640, root-owned, and the AP is gone) but inconsistent with the deliberate choice not to log it.

One thing for this repo

Not a defect, but it shows up in the measurements: the gate logs four lines per tick, 282 ticks a day, ~8% of all journal volume on a healthy wired screen in perpetuity. Given the journal here is volatile and /api/v2/system/logs (#3423) now reads it, that competes with the history someone needs after a fault. Measurements and a suggested shape in #3268, which already tracks this class of problem.

The rig is back to its prior state: test container removed, QR artefacts cleaned, radios re-blocked on both boards I touched.