Captive page very slow

[FYI, I edited your post’s title to be something more meaningful.]

I use some iPhone such as iPhone6,6s,SE,that could popup authentication page quickly … However, I use iPhone7 and iPhone X that popup authentication page very slowly, which takes about 50 seconds.

What I recommend you do here is use a packet trace to compare how these two devices load your captive portal page. That should give you some idea of what’s causing the slowdown.

I recommend that you use RVI for this (see Recording a Packet Trace), because that will show you if some traffic is going over WWAN.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thank you for your reply.During this period of time,I made new discoveries.If I restore the iPhone to factory settings,it could popup authentication page quickly while it did slowly before.And it will get well after I closed the "WiFi-Assist" in iPhone 8,while it won't in iPhone X.I don't know what the reason is.

Now it seems that I found a solution from Apple Developer Forums.If I could kill the "wifi helper" process in the iOS task manager,maybe iOS will not call the hotspot helper of apps,.So there is no interference from other app hotspot helpers,and the timeout problem of this first connection should also be avoided.

The problem is how to manager process?How to kill the "wifi helper" process?Is there a tool that could kill IOS process easily?I use the "libimobiledevice" for development,but I am not sure whether it is effective or not.(https://www.libimobiledevice.org/)

Looking forward to receiving your reply.

Is there a tool that could kill IOS process easily?

No. In general the iOS sandbox prevents an app from affecting other apps or the system as a whole, and thus there’s no supported way to kill other processes.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thank you for your reply.I want to tell you some about situations I met.I uesd my iPhone X to link the WiFi in the Starbucks.And it also took 45 seconds to popup authentication page Automatically.Is there any way to shorten the time? I hope the authentication page will be popuped more quickly.

Looking forward to receiving your reply.

Is there any way to shorten the time?

As with all optimisation issues, you need to measure the problem before you can plan a solution. Which brings me back to my 12 Feb post. Once you have an understanding of what’s happening on the ‘wire’, you’ll have a place to focus your investigations.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I too see same issues and one of customer deployments this is a major issue with all new iphone users, android and ipad/mac-book works perfectly fine. We did some packet captures and what we found was iphone with 12.X IOS versions have this behavior, they will connect fine and do a request out for captive portal detection and then after the response they will just keep sending 802.11 NULL frames to the WiFi router and after 45-60 seconds it will start sending DNS query for the given captive portal domain and then the auto sign up sheet pops up, We did many rounds of test and packet capture and this behavior is very consistent on iphone X running 12.X IOS versions. We had one iphone 5c running older IOS version and it just works perfectly fine along with IPAD and MAC Books.

Packet Analysis with iphone10X running IOS 12.X version:

802.11 association is complete with timestamp of 3.3 seconds

There is DNS query for captive.apple.com at 3.5 seconds

There is GET request from CNA browser for HTTP GET /hotspot-detect.html. One can see the User-Agent field here "CaptiveNetworkSupport-355.200.27 wispr" which is used by this CNA browser AKA auto sign up application by IOS devices. This is at 3.8 seconds of timestamp.

At 4.09 seconds the WiFi router has responded with HTTP 307 redirect code with complete URL of the captive portal.

After this iphone keeps sending NULL data frames to the WiFi router for which it keeps responding and it goes on for next 45 seconds.

At 49.04 seconds of timestamp we see a DNS to www.apple.com for which it gets a response and it sends another GET request for "/" on appple.com IP address.

Finally at 49.28 seconds of timestamp it sends the DNS query for the domain name as used by this captive portal and then finally it does request to this captive portal and the login page comes up. Also this duration is a bit random so it takes somewhere between 45-60 seconds to show that login page in this CNA browser. Till then user has no clue what is going on or he might just assume he had Internet access and tries to use his apps which may complain of no Internet connection.

It will be nice if IOS team can fix this delay in their Captive Portal Network Assit application and push this fix soon.

We have observed the same issue at various public locations using captive portals including our own solution. Apple please comment on the above behavior and whether this is going to be fixed.

Thanks

Our company runs many captive portals worldwide, this behavior began cropping up at a handful of sites starting early June. The concentration of the reports is from United States / California (unsure if this is relevant to the pattern). We have run several packet captures and are seeing results nearly identical to KunalFromSanJose. 40 to 80 seconds for the CNA page to appear consistently and only for iOS devices. We have many Californa based sites and not all of them are reporting the issue but at the sites that are reporting the issue, the problem is consistent.

Has anyone on this thread seen this issue resolved or determined any steps that were helpful in the resolution of the issue?

I too have started seeing this behavior, with the same delays and DNS lookups as reported above. First lookup to "captive.apple.com" then about 48s later a lookup to "www.apple.com" which finally triggers the captive-network-assistant pane to drop down a second or two later.

I have as case open with my WiFi vendor, but it sounds like I'm going to need to open an Apple case also.

Thanks for confirming my suspicions!

23 July 2019 update:

iOS 12.4 still appears to have this issue. We have filed a support case with Apple.

This is definitely on the Apple side. I've observed it with iPhone X and XS devices running 12.4, connecting to a variety of AP brands and captive portal systems (Wayport, Boingo, just today alone.)

Hi Anyone, have found any workaround for this issue we have the same problem with Iphone 13 IOS 15.2.1

"After this iphone keeps sending NULL data frames to the WiFi router for which it keeps responding and it goes on for next 45 seconds."

There is a consistent delay of 45 seconds in the display of the splash page.

With android devices or IOS version 14.X there is no problem.

It’s 2024 and this problem still exists on iOS 17.5.1, iPhone 11

Apple, can you hear us? I’m guessing not, these forums rarely result in attention or comments from Apple.