Hi all!
I didn’t even think that I would return to this case, but prompted me to remember and talk about a personal experience when a little over a year ago I had to spend quite a lot of time studying the problem with a Cisco-based wireless network and iPhones. I was instructed to deal with the question of one of the leaders: “Why, after rebooting, the iPhone cannot automatically connect to a Wi-Fi network, and when manually connected, it asks for a username and password?”.
Information about the Wi-Fi network:
Wireless controller - AIR-CT5508-K9.
The controller software version is 8.5.120.0.
Access points - in the bulk of AIR-AP3802I-R-K9.
The authentication method is 802.1x.
RADIUS server - ISE.
Problem customers - iPhone 6.
The client software version is 12.3.1.
Frequency 2,4GHz and 5GHz.
Finding a problem on the client
Initially, there were attempts to solve the problem with a swoop on the client. Fortunately, I had the same phone model as the applicant and was able to test at my convenience. I checked the problem on my phone - indeed, immediately after turning it on, the phone tries to connect to the corporate network previously known to it, but after about 10 seconds it remains unconnected. If you select the SSID manually, the phone asks you to enter your username and password. After entering them, everything works correctly, but after a reboot, the phone again cannot automatically connect to the SSID, despite the fact that the login and password have been saved, the SSID was in the list of known networks, auto-connection is enabled.
Unsuccessful attempts were made to forget the SSID and re-add it, reset the phone's network settings, update the phone via iTunes, and even update to iOS 12.4 beta (the latest at the time). But all this did not help. The models of colleagues were also checked - iPhone 7 and iPhone X, the problem was also reproduced on them. But on Android phones, the problem is not fixed. Additionally, a ticket was created in the Apple Feedback Assistant, but no response has been received to date.
Troubleshooting the Wireless Controller
After all of the above, it was decided to look for a problem in the WLC. In parallel, I opened a ticket in Cisco TAC. On the recommendation of TAC, the controller has been updated to version 8.5.140.0. Played around with different timers and Fast Transition. Did not help.
For testing, I created a new SSID with 802.1x authentication. And this is the turn - the problem is not reproduced on the new SSID. The TAC engineer's question makes you wonder what changes we made to the Wi-Fi network before the problem manifested itself. I’m starting to remember ... And there is one clue - the initially problematic SSID had a WPA2-PSK authentication method for a long time, but to increase the security level, we changed it to 802.1x with domain authentication.
I check the lead - I change the authentication method on the test SSID from 802.1x to WPA2-PSK, and then back. The problem is not reproduced.
I need to think more sophisticated - I create another test SSID with WPA2-PSK authentication, connect a phone to it, remember the SSID in the phone. I change authentication to 802.1x, authenticate the phone with a domain account, turn on auto-connect.
I reboot the phone ... And yes! The problem recurred. Those. the main trigger is changing the authentication method on a known SSID phone from WPA2-PSK to 802.1x. I reported this to the Cisco TAC engineer. Together with him, they reproduced the problem several times, took a traffic dump, in which it was clear that after turning on the phone, it starts the authentication phase (Access-Challenge), but after a while sends a diassociation message to the access point and disconnects from it. This is clearly a client side issue.
And again on the client
In the absence of a support contract with Apple, there was a long but successful attempt to get through to their second support line in which I told about the problem. Then there were many independent attempts to find and determine the cause of the problem in the phone and it was found. The problem turned out to be in the enabled function "". Quite a useful feature, which I and the complainant did not want to disable on phones for workaround. According to my assumption, the phone cannot overwrite information about the connection method to known SSIDs on iCloud servers. The find was reported to Apple, to which they admitted that this problem exists, is known to the developers, and will be fixed in future releases, which one was not reported in. Not ready to say how things are at the moment, but in early December 2019 the problem was still reproduced on the iPhone 11 Pro Max with iOS 13.
Conclusion
For our company, the problem was solved safely. Due to the fact that the company name was changed, it was decided to change the corporate SSID as well. And the new SSID was already immediately created with 802.1x authentication, which was not a trigger for the problem.
Source: habr.com