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

[Daemach]

How do you set up wireshark to sniff this?

[tablatronix]

ugh apple is useless
https://discussions.apple.com/thread/250240069

Submit feedback I guess..

[bfaliszek]

https://www.reddit.com/r/iOSBeta/comments/bptxxr/bugs_wifi_especially_captive_portal_just_terrible/
It seems that more people have a problem with it. I have iOS 12.4b2 and it does not work properly with me.

[bfaliszek]

Change the iPhone wifi settings to Manual IPv4 configuration and enter:
IP Address: 192.168.4.2
Subnet Mask: 255.255.255.0
Router: 192.168.4.1
It does not break the connection to the network. However, you have to open the browser yourself and enter 192.168.4.1. There is a captive portal WiFiManager available.

[tablatronix]

you can always open the browser yourself, why would you have to set static ips ?

[bfaliszek]

without setting the static IP in the settings, after about 5 seconds, the network will be disconnected. I will not be able to open browser, enter address, and log in to the correct network

[tablatronix]

oh mine doesn't disconnect, It just never opens the captive portal , hmm I wonder if this is something else or 2 issues..

[tablatronix]

@bfaliszek you might want to turn on esp debugging and get some detailed logs of the phy client disconnecting

[bfaliszek]

I recently installed iOS 13 beta 1 and everything works well. I think Apple finally fixed it.

[tablatronix]

Nice I will see if any changes on my side.

[tablatronix]

Just got this from apple

Hi Shawn,
There are changes in build 17C5046a that may have resolved this issue.
Has this issue been resolved after installing 17C5046a?

[bfaliszek]

@tablatronix I also received such an email. Apple has already fixed this in iOS13b1. Since then I have not had problems opening the captive portal.

[erikhjertholm]

Hi, I'm having troubles connecting to both a Mac and an Android phone. I'm able to connect to the network on both of them, but the portal does not appear, and I'm not able to connect by entering the ip address in a browser either. Maybe some more updates? Have you tried it lately? @tablatronix

[tablatronix]

Yeah this has been working fine since the last update. Not sure what you issue might be.