Wireless Access

Symptom - iOS Phone 30 second delay on first attempt on open SSID

When connecting to an open ssid for the first time, it takes about 30 seconds before the Wi-Fi icon appears and Wi-Fi can be used. This problem can be reproduced when the Wi-Fi network is forgotten.

Hardware used for this test

• Aruba 7205 Cluster based on ArubaOS 8.3.0.0, with Aruba AP-315 accesspoints
• Aruba VMC Cluster based on ArubaOS 8.4.0.0, with Aruba AP-205 accesspoint
• Unify AC-Lite accesspoint with firmware 3.9.54.9373
• iPhone 8 with firmware iOS 12.1.4
• iPad 2 with firmware iOS 9.3.5
• Samsung Galaxy S6 Edge with firmware Andriod 7.0
• HP Elite X2 with Windows 10 (Build 1709)

Conclusion

When connecting to an open ssid for the first time, it takes about 30 seconds before the Wi-Fi icon appears and Wi-Fi can be used. This phenomenon only occurs on both tested iOS devices and not on Android or Windows.

This phenomenon only appears to an open ssid and doesn’t happen when connection to an  WPA2-AES encryption or remembered ssid.

In the Aruba controller scenario, the “show user-table” directy see and can ping the iOS client directly from the controller. The Wi-Fi symbol on the iOS client side shows up 30 seconds later, in that time window a client cant use Wi-Fi.

This is a client side decision seen on iOS devices and is not a configuration issue on the WLAN controller side.  

I would type "show auth-tracebuf client-mac mac <mac address of client>" to see what is wrong or enabled using debugging for that client, to see what could possibly be wrong.

Hi cjoseph,

Thanks for your suggestion, much appreciated.

I test my iPhone against to another independent open Wi-Fi's in public area this evening and see the same behavior. Its clear to me this must something in iOS, i test this with 5 different iOS devices so sure its more than a just a iOS setting.

When the SSid is not already known on the phone, it takes 30 seconds on an open WiFi. The same also explains the behavior that captive portals not directly pop up but also after 30 seconds. I see this only iOS devices and not at OSX, Windows, Andriod, etc.

When a captive portal ssid was logged in before and the ssid is remembered by the iPhone, the captive portal pop-up directly and smooth.

I think this i a behavior just how iOS is designed :(.

show auth-tracebuf mac 40:9c:28:6a:86:5f

Feb 24 00:19:04  station-up             *  40:9c:28:6a:86:5f  f0:5c:19:24:92:30  -      -  open system

Feb 24 00:19:04  user repkey change     *  40:9c:28:6a:86:5f  f0:5c:19:24:92:30  65535  -  000c298d5a5300000003003a

Feb 24 00:19:04  macuser repkey change  *  40:9c:28:6a:86:5f  f0:5c:19:24:92:30  65535  -  40:9c:28:6a:86:5f

Feb 24 00:19:05  user repkey change     *  40:9c:28:6a:86:5f  f0:5c:19:24:92:30  7      -  000c298d5a5300000003003a

Feb 24 00:19:05  macuser repkey change  *  40:9c:28:6a:86:5f  f0:5c:19:24:92:30  7      -  40:9c:28:6a:86:5f

Feb 24 00:19:05 ipuser repkey change * 40:9c:28:6a:86:5f f0:5c:19:24:92:30 7 - 172.16.200.110

There is nothing conclusive from that output.  Did you get the user debug?

All works now without any delay anymore. strange thing is that i changed nothing!. and it works for two totally different wlan enviorements on both two of my ios devices. Little bit a strange situation but i still blame the working of iOS and not the controllers or unify ubiquity wlan enviroments (totally separated). Seems like iOS do something in the background i cant figure out.

Even my another ssid "HomeLAB-Guest" shows up the captive portal fast after connecting again.And respond normal again.

Below the user debug logging. (i reconnect to ssid TEST a couple of times).

(mm01) ^[mm] (config) #logging user level debugging
(mm01) ^[mm] (config) #write mem

(mm01) [mm] (config) #show log user 10

Feb 24 16:16:07 :542000:  <7473> <DBUG> |ucm|  entered in the function ucm_handle_sta_delete_channel_events

Feb 24 16:16:07 :542000:  <7473> <DBUG> |ucm|  entered in the function ucm_handle_sta_delete_channel_events UCM_VC_LEAVING_AP

Feb 24 16:16:18 :542000:  <7473> <DBUG> |ucm|  ucm_handle_sta_add_replay_channel_events: BSSID changed for staion mac 40:9c:28:6a:86:5f:  

Feb 24 16:16:25 :542000:  <7473> <DBUG> |ucm|  entered in the function ucm_handle_sta_delete_channel_events

Feb 24 16:16:25 :542000:  <7473> <DBUG> |ucm|  entered in the function ucm_handle_sta_delete_channel_events UCM_VC_LEAVING_AP

Feb 24 16:16:25 :542000:  <7473> <DBUG> |ucm|  ucm_handle_sta_add_replay_channel_events: BSSID changed for staion mac 40:9c:28:6a:86:5f: 
 
Feb 24 16:16:48 :542000:  <7473> <DBUG> |ucm|  entered in the function ucm_handle_sta_delete_channel_events

Feb 24 16:16:48 :542000:  <7473> <DBUG> |ucm|  entered in the function ucm_handle_sta_delete_channel_events UCM_VC_LEAVING_AP

Feb 24 16:16:57 :542000:  <7473> <DBUG> |ucm|  ucm_handle_sta_add_replay_channel_events: BSSID changed for staion mac 40:9c:28:6a:86:5f:  

Feb 24 16:39:54 :524148:  <6102> <DBUG> |authmgr|  PMK aging: start-index  175 end-index 199 (visited, deleted) kcache (0, 0) pcache (0, 0)