Problems on Apple devices using splash page authentication.

Here to help

Problems on Apple devices using splash page authentication.

We're having problems on Apple devices using splash page authentication. Units are MR52 and MR33 models. Below are some scenarios..


1. Iphones disconnects when roaming to a different AP which requires the user to login again to our splash page. Android units does not experience this. (splash page expiry is 7 days).


2. Iphones disconnects or disassociates when idle. Others need to login again and some just need to tap the SSID and regains connectivity, others need to on/off the wifi icon. Android units does not experience this.


Still doing tests on different iphone models and OS.

Will open a case soon... maybe some of you had already experienced this?



14 Replies 14
Kind of a big deal

Yes, can confirm this, have this too, but was too lazy to fix it at the moment haha

But yes, when I use my andoid I can leave for minutes/hours come back to the wifi and I´m back online without doing anything.


Please share youtcase when you can a reply / solution.

Getting noticed

Yes. We opened a case two days ago with the same symptoms. I encourage you to open one as well. We free to reference our case: 04178048

Kind of a big deal
Kind of a big deal

We have the exact same issues. I opened a case couple weeks ago without any way to fix it. 


Open SSID , IOS only and MR33/MR32 running on the 25.13 firmware. This is really annoying and currently affecting over 7k of our users.

Already submitted a case yesterday. No solutions yet. Support guy just wants to enable 802.11r but its not supported on an Open SSID.

Kind of a big deal
Kind of a big deal

Hmm I don't want to throw a brick on that support guy but he's clearly unqualified to handle wireless cases then.
There is no 4-way handshake on an open SSID so 802.11r can't be used.

Building a reputation

Subscribing as I have the same issue with countless users.  Fortunately its just for non-critical devices as it is just for personal phones, but its still something I hear about almost daily. 



For those who had opened a case... Can you copy/paste their solution or replies just to compare. Because there's still no solution. I haven't looked yet on Apple's support site if there's a similar case.


Here's mine..

Reply 1:
In regards to the issues with Apple devices:

1) For the roaming issue, I recommend enabling 802.11r on the SSIDs that support it. This will assist iOS devices with roaming

2) This is expected with all Apple devices (iOS, macOS) most likely due to power saving features. There are settings in the apple device that can be used to prevent this from happening. A simple google search regarding "apple device disconnect from wifi when locked" will provide some fixes. here is one example:



Reply 2:


Typically roaming is a client side decision. The best way to approach this to take monitor mode packet captures when trying to roam to another AP. what the does is a device monitors the wireless traffic and shows the communication between the client device and the AP. This will require a Macbook (or kali linux) and configure the Macbook wireless NIC to be in monitor/promiscuous mode. You will then take configure the channel and channel with of the AP that a device will be roaming to.(ie roaming from ap1 to ap2, take set up the monitor mode for ap2).

Here is our documentation for taking monitor mode captures:



Getting noticed

Pcap analysis:


I see that the EAPOL handshake is failing after the second message meaning the AP is not responding back. The device keeps trying and at one point the AP simply starts deauthenticating.


Seems like an AP problem.

Hi Randhall,


So you did the packet capture. Thanks for the info. Will try to do that later. We are still doing some test... Iphone7 12.3.1 and 12.4.1 seemed ok on roaming between APs. Idle disconnection or disassociation from AP is also not experienced. I'm not sure if the "auto join" option on iphone setting solved it.  (not familiar with settings, never had an iphone)

Kind of a big deal
Kind of a big deal

Any solutions yet ? 



None yet. Support just asked me if I want them to disable the 802.11k per AP. I said no. Since it works on android. And its a standard protocol for roaming. 


"The 802.11k standard helps to speed up its search for nearby AP's that are available as roaming targets by creating an optimized list of channels. When the signal strength of the current AP weakens, your device will scan for target AP's from this list."


I requested them to enable or show this option on the dashboard for the next feature update.

Comes here often

Hi guys,

I'm also having this issue. Will test the "auto-join" setting and see if that solves the issue.

Is there any possible solution?

Here to help

Facing same problem, is there any solution ?

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.