iphone taking 30 seconds to open captive portal

[tablatronix]

This is new, I rolled back to esp 2.3 and its the same, must be a change in IOS, can anyone else confirm, seems like it does not launch until after several hits to the server

[tablatronix]

*WM: Request redirected to captive portal
*WM: Handle root
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Info
*WM: Sent info page
*WM: Request redirected to captive portal
*WM: Handle root
*WM: [2] WiFi Scan ASYNC completed in 2194 ms
*WM: [2] WiFi Scan ASYNC found: 6
*WM: [3] -> captive.apple.com 
*WM: [2] <- Request redirected to captive portal 
*WM: [2] <- HTTP Root 
*WM: [3] -> 192.168.4.1 
*WM: [3] lastconxresult: WL_IDLE_STATUS
*WM: [2] Scan is cached 5451 ms ago
*WM: [3] -> captive.apple.com 
*WM: [2] <- Request redirected to captive portal 
*WM: [2] <- HTTP Root 
*WM: [3] -> 192.168.4.1 
*WM: [3] lastconxresult: WL_IDLE_STATUS
*WM: [2] WiFi Scan ASYNC started 
*WM: [2] WiFi Scan ASYNC completed in 2193 ms
*WM: [2] WiFi Scan ASYNC found: 8
*WM: [2] Portal Timeout In 116 seconds
*WM: [2] Portal Timeout In 86 seconds
*WM: [2] <- HTTP Root 
*WM: [3] -> www.apple.com 
*WM: [2] <- Request redirected to captive portal 
*WM: [2] <- HTTP Root 
*WM: [3] -> 192.168.4.1 
*WM: [3] lastconxresult: WL_IDLE_STATUS
*WM: [2] WiFi Scan ASYNC started 
*WM: [3] -> www.apple.com 
*WM: [2] <- Request redirected to captive portal 
*WM: [2] <- HTTP Root 
*WM: [3] -> 192.168.4.1 
*WM: [3] lastconxresult: WL_IDLE_STATUS
*WM: [2] WiFi Scan ASYNC started 
*WM: [2] WiFi Scan ASYNC completed in 786 ms
*WM: [2] WiFi Scan ASYNC found: 6

40 seconds, wtf

[mozzhead164]

Any updates on this issue yet? My ESP is doing exactly the same, however I am on an old version of iOS (10.3.3). It's taking a good 30-40secs to connect, but connecting with a laptop takes <5seconds.

I'm using core 2.5.0, arduino 1.8.9 and Wifimanager-Dev branch from GitHub

[tablatronix]

From what I can tell it is ios only, maybe a dns issue or something ios changed, I will need some more observations from users and other captive portals

[agrath]

@mozzhead164 can you try rolling back to core 2.4.2 - see #866 (just curious to see if you get different behaviour here)

[tablatronix]

I tried 2.3 as in first post

[agrath]

@tablatronix wouldn't you expect there to also be differences between 2.3 and 2.4.2? I am just wondering if this is the same upstream issue as identified in #866
I've got an iphone so I could test this if it would help, I have an iPhone 7, running iOS 12.2

[tablatronix]

I do not see any change in esp lib, I am leaning towards ios itself, you can clearly see the hits the os just does not launch the captive portal until 3rd hit, that does not mean that there is not some workaround or specific data is expects now

[agrath]

@tablatronix I'll test this on my iphone against 2.3 core and see if I can also get apple-side debug logs

[agrath]

@tablatronix I think I can reproduce this on my phone.

iPhone 7 running iOS 12.2
Built WifiManager from commit 4873c7c against esp8266 core 2.3.0

Unfortunately the iOS logs did not appear to contain any detail about connection attempts, captive portal etc.
I couldn't find any reference to captive/esp across the whole log file (around 700 lines for the few minutes I was tailing it)
I am on windows but was tailing the device log using imobiledevice idevicesyslog.exe

I tried a few different times with varying results but usually in the log was three redirects to root. Different behaviour on the device such as sometimes the captive portal appearing and disappearing a few times, other times it would just take ages to open the browser window. Once it worked nearly instantly.

I have attached the log from WM
wm_esp.log

[agrath]

@tablatronix

I captured the page body that's generated along with the content length that was sent.
Manually verifying this in a text editor it doesn't seem to match.
The content length is being sent as 3368 (this is the log line right between HTTP Root Page and the dashes) but when manually checking between the start of the doctype (between the ! in serial log) and the end of </html> (which appears to have a trailing space) I get 3371

Here's the code I used:

void WiFiManager::handleRoot() {
  DEBUG_WM(DEBUG_VERBOSE,F("<- HTTP Root"));
  if (captivePortal()) return; // If captive portal redirect instead of displaying the page
  
  handleRequest();
  DEBUG_WM(DEBUG_VERBOSE,F("HTTP Root Building"));
  String page = getHTTPHead(FPSTR(S_options)); // @token options
  String str  = FPSTR(HTTP_ROOT_MAIN);
  str.replace(FPSTR(T_v),configPortalActive ? _apName : WiFi.localIP().toString()); // use ip if ap is not active for heading
  page += str;
  page += FPSTR(HTTP_PORTAL_OPTIONS);
  page += getMenuOut();
  reportStatus(page);
  page += FPSTR(HTTP_END);
DEBUG_WM(DEBUG_DEV,F("HTTP Root Page"));
DEBUG_WM(DEBUG_DEV, "content-length:"+String(page.length()));
DEBUG_WM(DEBUG_DEV,F("-------------"));
DEBUG_WM(DEBUG_DEV, "!"+page+"!");
DEBUG_WM(DEBUG_DEV,F("-------------"));
  server->sendHeader(FPSTR(HTTP_HEAD_CL), String(page.length()));
  server->send(200, FPSTR(HTTP_HEAD_CT), page);
  // server->close(); // testing reliability fix for content length mismatches during mutiple flood hits  WiFi_scanNetworks(); // preload wifiscan 
  if(_preloadwifiscan) WiFi_scanNetworks((unsigned)20000,true); // preload wifiscan throttled, async
  // @todo buggy, captive portals make a query on every page load, causing this to run every time in addition to the real page load
  // I dont understand why, when you are already in the captive portal, I guess they want to know that its still up and not done or gone
  // if we can detect these and ignore them that would be great, since they come from the captive portal redirect maybe there is a refferer
}

I attach the raw log (copy and pasted from visual studio) and the raw body which I'm getting 3371 bytes from (content length is sent as 3368)

wm-log.txt
http-raw-body.txt

[tablatronix]

Thanks, I have not have time to break out wireshark and do some testing