football2801
4454e9a8a5
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>