Captive portal takes more than 1 minute to appear on iOS and Android Devices

Starting wifi-connect on-boot or even manually and letting iOS and Android devices connect to the access point (AP) takes more than a minute for the captive portal login screen to appear on the device’s default browser. However, connecting to the AP via laptop or desktop computer experiences little to no-delay.

This is in reference to issue#279 on the balena wifi-connect repository.
Here’s the url: [].

As mentioned by @majorz, the application is written in Rust, therefore, it is compiled as native. I suspect that it has something to do with how mobile operating systems deal with captive portals in general and how wifi-connect currently doesn’t have a mechanism to deal with this.

Referencing one of @charliesneath’s research.
Here’s the url: []

I am not really familiar with this, so I am asking help in locating where wifi-connect fulfills one of these rules, if not it would be great if you guys can point me to the right direction so I can modify it on my end. Thank you so much and any insight would be greatly appreciated.

Hi @FaitAccompli,

If I am able to reproduce that locally it should not be that hard to find out the reason, but up until now I never reproduced this. I have tested this with multiple iOS and Android devices and never experienced this. The captive portal always opens quickly on my side. I have not tested on those newer iPhones though - should be able to do a check with iPhone 12 next week though.

Can you please provide as much details as possible on how wifi-connect is started? I am starting to wonder whether this is an issue outside the phone OS and wifi-connect, but somewhere in the middle like the particular OS environment or device WiFi chip. So the more details you provide the easier would be to narrow that down. Also are you running this with balenaOS or Raspbian, etc.?


1 Like

Thank you so much, I was able to reproduce this problem using an iPhone6 with iOS 12.4.8. Some users using Android devices also experienced this. I am using a headless RaspberryPi Zero W running Raspios Buster Lite. I’ll be sending more details about how I setup and run wifi-connect on my device. In addition, a screenshot of the processes running and also the device WiFi chip.

P.S. My friend did not experience this delay and he was using an iPhone 6S with iOS13. Thank you, I’ll update first thing tomorrow.

Do you have a different RaspberryPi device type to try that on as well? So that we know whether it is the device type or not the issue.

Sadly, I only have RPi Zero W’s. I’ll try to contact some people who have one and check if the issue persists. Thank you @majorz.

Hi @FaitAccompli – thanks for the additional info, and please let us know how it goes for you!

All the best,

Hi pleasure to meet you @saintaardvark and @majorz. Here’s what I got so far.

Device specifications

OS Release
PRETTY_NAME=“Raspbian GNU/Linux 9 (stretch)”
NAME=“Raspbian GNU/Linux”
VERSION=“9 (stretch)”

Kernel Version
Linux sm-deploy 4.19.66+ #1253 Thu Aug 15 11:37:30 BST 2019 armv6l GNU/Linux

CPU info
processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 997.08
Features : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7
Hardware : BCM2835
Revision : 9000c1 (PiZero W)
Serial : 000000002dd906bb

Wifi-connect is configured to run on boot and the looks like this:

#Check if there’s an active connection

if [ $? -eq 0 ]; then
    printf 'Skipping WiFi Connect\n'
    printf 'Starting WiFi Connect\n'
    sudo wifi-connect -s SSID_NAME -p PASSWORD123_ -u /home/pi/ui


# Start your application here.

The systemd script to launch wifi-connect on boot came from @libbymiller’s tutorial

sudo nano /lib/systemd/system/wifi-connect-start.service


Description=Balena wifi connect service



And was enabled using the ff. command:
sudo systemctl enable wifi-connect-start.service

Wifi-connect is served at the default ip address and port:

Additional info that might help

Kinda far fetched but I initially assumed it was caused by a memory leak but the output when typing in the “free” command on the terminal (not running wifi-connect cause I’m connecting via ssh and it will disconnect my session).

pi@sm-deploy: ~$ free

Shows the following:

Same goes when running the “top” command (not running wifi-connect cause I’m connecting via ssh and it will disconnect my session)

I’ll be setting up a monitor and I’ll be observing the behavior when I run wifi-connect manually and run these commands. I’ll be adding more insights as we progress. Thank you so much and I hope to hear from you guys.

That’s really useful information. I will test with your exact setup on Monday and report back. Will check this with two iPhone models including latest and with a couple of Android devices. Hopefully we will catch it this time - if I am not able to reproduce I will think of a list of commands for you to run on your side so that we gather helpful diagnostic information.

1 Like

Hi there @majorz, I would like to ask if there are updates on your end?

Hi, I have been looking into this and got some initial results - not sure it is exactly the same issue, but it is an odd behavior with the captive portal not showing. I will let you know once I know more about this.

So it turned out to be some different issue that I encountered with one of the phone models I tested with. On the other ones I had I could not reproduce this at all.

What I noticed though is that when I installed the full version of Raspbian (not the lite one), there was a bigger delay with opening the captive portal. Like a few seconds more, but nothing close to 1 minute. The reason for this is the really slow CPU the Zero has and the small amount of memory.

Are you running the full Raspbian version and do you have any extra software installed on the device while reproducing this? I am starting to think it may be related to the low resources the Zero has.


1 Like

Thank you @majorz for this. Actually, come to think of it, I’ll be comparing the boot up speed of the captive portal having only wifi-connect installed and our actual setup. Our Zero right now sends sensor data to the cloud on regular intervals, multiple python scripts also run on boot and is continuously performing writes with our database deployed on ec2. I have to monitor the processes and how much the CPU is used. I’ll ping back with my updates. Again, thank you for this insight.