Captive portal takes up to 1min to appear via iOS

[charliesneath]

When testing out wifi-connect, it can take up to 1min after connecting to the WiFi Connect network for the captive portal login screen to appear. The portal is being served from a Raspberry Pi Zero W, and without any modifications after a fresh install.

The captive portal appears without delay when joining the WiFi Connect network from my laptop.

Is there a way improve response time when the portal is being created from the RPi?

[majorz]

@charliesneath It should not take this long for the captive portal to show up. Since the application is written in Rust, it is compiled as native code, so it will run quickly. Can you check whether you have some other processes running on the device which occupy the CPU. Using the htop command or just top could be helpful.

[charliesneath]

@majorz Agreed, confused because the behavior is new (I think!) and I can't point to an obvious change that's incurring the delay. There isn't any significant CPU usage with the RPi0W (hovers around 5%).

I can consistently reproduce the issue when connecting via iOS, but there's no delay in seeing the captive portal when connecting via laptop. This makes me think it's something with the device specifically?

This triggers immediately when connecting with an iPhone:

"GET /hotspot-detect.html HTTP/1.0" 302
"GET / HTTP/1.0" 200

But there's about a 45s delay until this:

"GET / HTTP/1.1" 302
"GET / HTTP/1.1" 200

after which the files for the portal start to load and it reads User connected the the captive portal.

Does this provide any additional insight? Let me know if there's any more debugging info that would help.

[charliesneath]

@majorz Just tested with an iPad and could not reproduce. This must be an issue with the specific iPhone.

If you have any additional things to try, please let me know. Otherwise, you can close this issue and I'll re-open if I get anymore specific information.

[charliesneath]

@majorz I'm still having this issue, and digging around I'm seeing similar reports of this behavior with iOS. This is beyond my expertise, but is it possible that Apple has changed the way that iOS 12 interacts with potential captive portals?

I've been monitoring CPU usage when trigging sudo wifi-connect (without additional options) and don't see anything unusual. It still takes about 1min for the portal to appear.

My iPad, which is running iOS 11.4, doesn't have an issue. This is the output I see when connecting via iPad:

"GET /hotspot-detect.html HTTP/1.0" 302 -
"GET / HTTP/1.0" 200 -
"GET /hotspot-detect.html HTTP/1.1" 302 - *this part is delayed on the iPhone*
"GET / HTTP/1.1" 200 -

The output from wifi-connect isn't verbose enough to see if there are other issues, but please let me know of other information I can provide for debugging.

Is there any chance this is an issue with HTTP 1.0 vs HTTP 1.1?

I'm not sure how relevant or valuable these examples are, but the descriptions are similar to what I'm experiencing, and hint that there is some specific iOS behavior that could be the cause of the issue.

• https://stackoverflow.com/a/43924110/492976
• https://www.raspberrypi.org/forums/viewtopic.php?t=196231
• https://community.ubnt.com/t5/UniFi-Wireless/Captive-Portal-Apple-IOS-devices-failing-to-redirect/td-p/2618351
• https://forums.developer.apple.com/thread/113712
• https://medium.com/@rwbutler/solving-the-captive-portal-problem-on-ios-9a53ba2b381e
• https://apple.stackexchange.com/questions/298060/ipad-doesnt-display-the-captive-portal-login-window-after-connecting-to-a-wifi

[charliesneath]

@majorz Do you foresee any possible investigation into this issue? The fact that it works instantly from a Macbook, but takes 1min with an iPhone signals that there might be some iOS funkiness that's possible to resolve.

Thanks in advance, this seems like a complicated thing to dig into.

[electric1490]

hey @charliesneath ! quick follow-up on this: did you ever figure out a go-forward on this? I'm encountering the same exact issue as you and would love to know if there was a solve for it. Thanks!

[charliesneath]

@electric1490 No progress yet. I don’t have any expertise in this area but my suspicion is that newer versions of iOS handle the captive portal flow in a specific way, and wifi-connect is not taking into any account.

There isn’t much debug output from wifi-connect to see what’s happening, but there might be some issues resolving pages, etc. that are causing the delay...but I don’t know why it would then eventually work.

@majorz any chance you can revisit this, especially if something else has changes with upcoming iOS 13 update?

On Fri, Jul 5, 2019 at 6:50 PM electric1490 [email protected] wrote:

hey @charliesneath https://github.com/charliesneath ! quick follow-up on this: did you ever figure out a go-forward on this? I'm encountering the same exact issue as you and would love to know if there was a solve for it. Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/balena-io/wifi-connect/issues/279?email_source=notifications&email_token=AAEUFBT6DNM5CYNNE6QWDVTP57FZTA5CNFSM4HCRMZL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZKNHCY#issuecomment-508875659, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEUFBX2BN7ZGLR6G7HTY43P57FZTANCNFSM4HCRMZLQ .

[FaitAccompli]

@majorz Just tested with an iPad and could not reproduce. This must be an issue with the specific iPhone.

If you have any additional things to try, please let me know. Otherwise, you can close this issue and I'll re-open if I get anymore specific information.

Hi @charliesneath and @electric1490, this issue persists not only on IOS devices but also Android as well. We've deployed more than 10 units and so far around 4 users are experiencing this problem both on Andoid and IOS. There isn't any issue when connecting via laptop. As mentioned by @majorz, "Since the application is written in Rust, it is compiled as native code, so it will run quickly." this should hold true, and I'm guessing it has something to do with processes running in the Raspberry PI. I'm currently running wifi-connect on a debian buster lite distro on RPI Zero W. I'll be posting my insights here once I can replicate the issue on local setup. If you guys (@charliesneath, @electric1490) have any updated insights it would be really helpful.

[jellyfish-bot]

[majorz] This issue has attached support thread https://jel.ly.fish/7beaa16b-a2aa-4869-8268-efba4b434a0e