Cisco ISE and Radius Server and wireless issues

[rschwart]

Long title for the problem. We recently installed new SSL Certificates on our ISE servers Version 1.4 and put patch 10 on the ISE servers as well.  The certificates are from inCommon. Since the patch and ssl certificate installs, we are having issues with some of our Apple devices on wireless. The clients attempt to connect 3 or 4 times, actually authenticate, get and ip address and then drop the session. Not all clients and not all apple devices. Has anyone seen or experienced this, and if so, what the solution may be. TAC as been working on this for a month and we are stilling having this issue. Below is what I get from ISE

se-psn2
Event	5440 Endpoint abandoned EAP session and started new
Failure Reason	5440 Endpoint abandoned EAP session and started new
Resolution	Verify known NAD or supplicant issues and published bugs. Verify NAD and supplicant configuration.
Root cause	Endpoint started new authentication while previous is still in progress. Most probable that supplicant on that endpoint stopped conducting the previous authentication and started the new one. Closing the previous authentication.

[nspasov]

I have seen this before and it was due to a bug with the WLC code. What version are you running on your WLC?

Also, do you have "AES Keywrap" enabled under the SSID?

Thank you for rating helpful posts!

[rschwart]

AES keywrap I don't see under the ssid, but I b believe that it would not checked.

We are running version 8.2.130.0

[nspasov]

Sorry, this setting is under the AAA Radius server configuration. Please check again. 

Also, is there a specific reason(s) that you are running 8.2.130 instead of the recommended 8.0.140.0 version? I am not a wireless guy but I have heard from several users that the 8.2 train has been very problematic. 

Thank you for rating helpful posts!

[rschwart]

AES keywrap is not enabled. We moved to the 8.2 because we are installing 3802i ap and you need 8.2 for them.

I am seeing this issue on one controller that is still on 8.0.133.0 also.

[rschwart]

Below is from a debug, where the client is getting a COA de-auth after an ipv6 request.

*apfLbsTask: Jan 13 14:08:27.350: c0:f2:fb:31:a3:d6 Copy IPv6 LOCP: fe80::412:e6bd:6087:da74

*radiusCoASupportTransportThread: Jan 13 14:08:32.788: c0:f2:fb:31:a3:d6 apfMsDeleteByMscb Scheduling mobile for deletion with deleteReason 6, reasonCode 252.