The previous protocol fix (302 → 200 portal HTML) didn't restore iOS
captive-banner reliability under the lock-screen-camera join: the user
joined, accepted the prompt, and got nothing on unlock. We're guessing
without data, so this round adds instrumentation alongside three
high-confidence behavioral fixes that are individually plausible
explanations.
Fixes:
* Force the AP DHCP server to advertise the AP IP as DNS via
esp_netif_dhcps_option(ESP_NETIF_DOMAIN_NAME_SERVER). Arduino-ESP32's
softAP doesn't set this explicitly; if a client comes in with cached
cellular DNS the captive DNS hijack gets bypassed and iOS resolves
captive.apple.com to real internet — no captive signal ever fires.
* WiFi.setSleep(false) so the AP radio doesn't park between beacons
and drop probe packets that arrive during a sleep window.
* Cache-Control: no-store on the portal response, so iOS doesn't carry
a "this SSID was fine last time" determination across forget+rejoin
cycles.
Diagnostics (logged on serial at 115200, in AP mode only):
* Every HTTP request: method, URI, Host, User-Agent. Tells us whether
iOS is reaching us and which CNA path it's hitting.
* WiFi AP events: STA-associated, IP-assigned, STA-disconnected.
Tells us whether the join completed and DHCP succeeded.
Repro: pio device monitor -e waveshare73-v1, forget the network on
the phone, lock + scan + accept, watch the log.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
football2801
4454e9a8a5