football2801
d1599a726d
After repeated 200-OK / DHCP-option / DNS-hijack permutations failed to
make the iOS captive banner fire reliably, port the configuration that
empirically works on the aqua-iq Pi to the ESP32:
* WPA2-PSK secured AP (was open). iOS handles secured-network
captive-portal detection more aggressively than open networks. The
PSK ('pictureframe') is baked into both firmware and the WIFI: QR so
the user never types it — there's no real secret value here.
* Explicit channel 6 (was the softAP default of channel 1). Channel 6
is the "middle" 2.4 GHz channel and tends to be less contested in
dense environments; aqua-iq picks it for the same reason.
* 1.5 s settle delay after softAP. The radio + DHCP server need a
beat before they're ready to handle a phone that joins the moment
the SSID is broadcast (aqua-iq sleeps 3 s for NetworkManager+dnsmasq
to fully initialize; the ESP softAP stack is faster but a small pad
still kills race conditions).
* CNA paths revert to 302 redirect → "/". This is what aqua-iq does
and what WiFiManager does. Serving the portal HTML inline at 200 on
these endpoints (the previous attempt) didn't reliably trigger the
iOS banner. The redirect is what iOS / Android / Windows look for.
QR string format updates from WIFI:S:NAME;T:nopass;; to
WIFI:T:WPA;S:NAME;P:pictureframe;; — phones consume both, but the
WPA variant is needed now that the AP requires a password.
Bg image's format-string footnote regenerated to match.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>