Apple Device iOS 11 connectivity problem.

[MM15]

iPad , iPhone with iOS 11 cannot associate to AP.

when i use my ipad and iphone connect to new SSID with authentication OPEN, my devices are disassociate but i use iphone with iOS 10 can connect to SSID normally.

anyone here got this problem with iOS 11 ?

[bjnesbitt]

Well after another round of IOS 11.x updates problem has resurfaced.  I now have a case open with Apple Enterprise support. According to the logs I sent, the device is reporting Dauth reason code: 7. 

AP sent request for Apple device to deauth and that never happens, so phone just gets stuck in an indefinite loop of connect/disconnect from our public WIFI with captive portal enabled.  Below is the output from the Apple's WIFI debugger diagnostics. 

The only way we can get device to reauth, is to force Deauth from the Cisco controller.  What we noticed on devices that have this issue, the IDLE time is more than the Session Tiemout.  So with session timeout value of 14400, you would expect by design the when device reaches an IDEL time of more than 14400 a forced deauth form controller would happen and client would pick that up and initiate a reauth.

<NOTICE>: Adding problematic state for XXXXXXXXXX, reason Deauthentication reasonData=7
<NOTICE>: __WiFiDeviceManagerUpdateNetworkProblematicState: ProbState Entries :<array> {
  0 : <dictionary> {
    problematicStateEntryReason : 4
    problematicStateEntryReasonData : 7
    problematicStateEntryTimestamp : 543178286.03785205
  }
}
03/19/18 13:51:26.039 <NOTICE>: Adding XXXXXXXXXXX to list of potentially problematic networks
03/19/18 13:51:26.039 <NOTICE>: problematic networks = xxxxxxxxxxxxx  and potentially problematic networks = XXXXXXXXXXX

[StefanJ]

Interesting. I'm not entirely sure if my story below is related, but it seems there's a timer issue somewhere ...

In my case we're using a Foreign-Anchor construction and on the Anchor WLC we're seeing lots of IOS clients (among others) stuck in a 'WEBAUTH_REQ' state. When I deauthenticate these clients on the Anchor WLC, they can reconnect again to the Webauth SSID.  I'm curious if that's the case for you as well.

You can run the following command on your WLC to see how many clients have this state:

(WLC) > show client state summary
Client State Summary
====================

State Number of Clients 
----- ----------------- 
DHCP_REQD 51 
WEBAUTH_REQD 607 
RUN 3442 
----- ----------------- 
Total 4100

You can then create a list with MAC-addresses of clients with this issue by running a grep command on your SSID (In my case the ID of my SSID is 1):

(WLC) >grep include "Associated    No" "show client wlan 1"
Press any key to continue.. 
00:6d:xx:xx:xx:xx 10.0.0.1 Associated No Mobile 4 No Export Anchor Unknown 
00:6d:xx:xx:xx:xx 10.0.0.1 Associated No Mobile 4 No Export Anchor Unknown 
...

Then check and compare how long these clients are in this state

(WLC) > grep include "Connected For " "show client detail 00:6d:xx:xx:xx:xx"   
Press any key to continue..
Connected For ................................... 6421 secs

They should not be in this state for longer than 300 seconds however if I have to believe the Web Authentication Timeout (correct me if I'm wrong)

(WLC) >grep include "Web Authentication Timeout" "show wlan 1"
Press any key to continue..
   Web Authentication Timeout.................... 300

We've had no changes on our controllers for at least 4 months, but this issue only surfaces recently since certain apple IOS updates.

I'm going to check some apple wifi debugger logging as you did.

[bjnesbitt]

Thanks for sharing what you are experiencing. I will ask our network architect if this applies to our situation too. Would you mind sharing what you find in the Apple WIFI debugger logging?

[Hoi Lam So]

Hi all, lucky I find this post. My client has similar issue and still not fix. Could you share how to do iPhone WiFi debugger? Maybe I can provide more information for our study. Thanks,

[anthonyTSRH]

I actually don't know how to do the debugging. But that's a great thought. BTW, we are still having the issue. I've made sure the the SSID and Profile name are all the same case (i.e. caps or lowercase) but still have the issue. What is weird is that my colleague and I both have iPhones running the same IOS. I have the disconnect issue and he does not. It seems to be something power related (like a power save feature or something)...but I can't find anything in the iPhone settings.

[bjnesbitt]

We finally were able to narrow down what was causing all our issues. When we disabled the captive portal login page all issues went away. What got us to the point of turning off the captive portal was due from reading logs that showed device not ever receiving an IP from our DHCP service. Apple also said the same thing when reviewing our IOS WIFI debug logs.

Our plan to keep this working, set captive portal to pass user without requiring authentication and send them to a landing page with a T&U posted for them to read or 🙈 not read before they continue on to use the network.

Ultimately it’s a bug that both Cisco and Apple need to work together on to find what has changed to fix issue.

[anthonyTSRH]

Great info...One challenge is that the SSID in question for me does not use captive portal. It's 802.1X authentication. But on another SSID that is on this same controller, we do use captive portal.

[bjnesbitt]

Does the one with the Capive Portal have users that report random disconnects and in ability to reconnect? What about the the 802.1X auth SSID?

[bjnesbitt]

Contact Apple support and request provisioning profile for the WIFI debugger. Once you load that profile that will enable the wifi debug option and create verbose logs that can be sync to computer using iTunes.

[Poorya Naji]

One quick question, what is your ssid name and profile name? Is it all capital letter or combination of capital and lower letters? i had same problem like you and my SSID name and Profile name was a combination of capital and lowercase letters. I changed them to all capital letter and problem solved. all iphones and ipads are now able to connect and stay connect!!!
Please leave your comments if it does solve your problem too!

[bjnesbitt]

They are mixed case. I am going to test this theory and report back my findings.

[anthonyTSRH]

I have a mixed case as well. Specifically, the "profile name" has lower case and upper case letters and the "SSID" is all caps...I'll test this theory as well. Question, changing the profile name is disruptive correct (meaning I'll have to take an outage on that SSID)??

[Poorya Naji]

Yes, but just for a second or two.

[bjnesbitt]

Anthony,

      Any update on your test after making the case change on your profile? 

[Poorya Naji]

Hi anthony,
Any news on your test?