Inspired by the production-proven approach in dirkhh/adsb-feeder-image.
1. DNS spoofing for automatic captive-portal popup (Change 1 — Critical)
Write /etc/NetworkManager/dnsmasq-shared.d/ledmatrix-captive.conf with
address=/#/192.168.4.1 before nmcli connection up so NM's built-in
dnsmasq (ipv4.method=shared) resolves every hostname to the AP IP.
This triggers the OS captive-portal popup automatically on iOS / Android /
Windows / macOS — no manual navigation to 192.168.4.1:5000/setup required.
New helpers: _write_nm_dnsmasq_captive_conf / _remove_nm_dnsmasq_captive_conf.
New constants: NM_DNSMASQ_SHARED_DIR / NM_DNSMASQ_SHARED_CONF.
2. Real internet connectivity check (Change 2 — High)
Add _check_internet_connectivity() (ping 8.8.8.8 + HTTP fallback).
check_and_manage_ap_mode() now considers a device "disconnected" when nmcli
shows connected but no real internet reachability, matching adsb-feeder's
multi-method gateway/DNS/HTTP test approach.
3. AP idle timeout (Change 3 — Medium)
Track _ap_enabled_at timestamp in enable_ap_mode(). Add _has_ap_clients()
using 'iw dev <iface> station dump'. check_and_manage_ap_mode() auto-disables
AP after ap_idle_timeout_minutes (default 15) with no associated clients.
4. Wrong-password error feedback (Change 4 — Medium)
_connect_nmcli() detects "Secrets were required" / "authentication rejected"
in nmcli stderr and prefixes the message with "wrong_password: ".
The /api/v3/wifi/connect route propagates error_type="wrong_password" in the
JSON response. captive_setup.html shows "Incorrect password — try again"
(keeping the form active) instead of the generic failure message.
5. Escalating watchdog NM restart (Change 5 — Low)
wifi_monitor_daemon.py tracks _consecutive_internet_failures. After
_nm_restart_threshold (5) consecutive checks where nmcli shows connected but
internet is unreachable, restart NetworkManager as a recovery step.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix: overhaul WiFi captive portal for reliable device detection and fast setup
The captive portal detection endpoints were returning "success" responses
that told every OS (iOS, Android, Windows, Firefox) that internet was
working — so the portal popup never appeared. This fixes the core issue
and improves the full setup flow:
- Return portal-triggering redirects when AP mode is active; normal
success responses when not (no false popups on connected devices)
- Add lightweight self-contained setup page (9KB, no frameworks) for
the captive portal webview instead of the full UI
- Cache AP mode check with 5s TTL (single systemctl call vs full
WiFiManager instantiation per request)
- Stop disabling AP mode during WiFi scans (which disconnected users);
serve cached/pre-scanned results instead
- Pre-scan networks before enabling AP mode so captive portal has
results immediately
- Use dnsmasq.d drop-in config instead of overwriting /etc/dnsmasq.conf
(preserves Pi-hole and other services)
- Fix manual SSID input bug that incorrectly overwrote dropdown selection
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: address review findings for WiFi captive portal
- Remove orphaned comment left over from old scan_networks() finally block
- Add sudoers rules for dnsmasq drop-in copy/remove to install script
- Combine cached-network message into single showMsg call (was overwriting)
- Return (networks, was_cached) tuple from scan_networks() so API endpoint
derives cached flag from the scan itself instead of a redundant AP check
- Narrow exception catch in AP mode cache to SubprocessError/OSError and
log the failure for remote debugging
- Bound checkNewIP retries to 20 attempts (60s) before showing fallback
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
