We have a 4402 controller using WPA 1 TKIP & 2 AES, and we are getting MIC Error counter measures on all AP's with clients connected.
Most clients are Intel, but I have tested with my Cisco card too, and the same thing occurs.....you are associated with an AP, then it forces the MIC counter measure, and forces all clients off for 60 seconds.
Is this a controller hardware issue? as its the same with a default config
I have the same problem on a WLC 4402-12 on 184.108.40.206 (lasted version), an di resolv the problem fo my pc using the lasted driver of intel card.
Thanks....this is the same as I found out today...
This is going to be a pain in the neck, especially when it comes to guest networks and there are some many laptops using the Intel 2200 driver and the Intel 3945ABG driver.
I believe this cannot be turned off...is this correct?
Have you tried this in a lab environment where you can console into the AP during this event?
My understanding is it has a lot to do with the self signed certificates not being accepted.
I was having a similar issue with converted 1232 AP's and changing them all to 1242 LAP models seems to have cleared it up.
I guess you could figure out how to make the certificates work but I was under the gun to get something in production immediately if not yesterday...you know how that goes.
this is an issue with WPA in the more recent versions of the controller software, but it is unable to turn off on the controller due to it being a standard.
in the past 3 weeks, I have had 4 customers with similar issue an the new drivers have resolved.
this is an issue with just the most basic WPA configuration.....no certificates at all
I've heard there is a workaround for this in the latest version of the WLC code. There apparently is a way to change the 60 second deauth period to 0, creating a workaround.
I haven't had time to download the latest firmware and check though...
Thanks for that....I managed to get this response from Cisco:
Per the WPA standard, if an AP should receive 2 or more MIC errored frames from a given client, then it is required to kick off all associated clients that are using TKIP and hold them off for 60 seconds.
The Intel clients are known to be susceptible to sending frames with MIC errors (so btw are 7920s, more rarely.) I believe that this problem has been fixed in the latest driver for the 2200/2915; unfortunately Intel has still not been able to fix the problem with its 3945/4965 clients. (We have not yet identified a client who is willing to sit still to let us troubleshoot this problem on a 3945.)
The workarounds for this problem, where you're getting hit by MIC errors from a client:
1. Use WPA2-AES instead of WPA-TKIP. It's a stronger crypto method and doesn't get MIC errors or have this 60-second holdoff thing.
2. Use dynamic WEP instead of WPA-TKIP. This is less appealing from a security standpoint, but may be the only way to go, if AES isn't an option (e.g. on the 7920.)
3. If you must use TKIP, then reduce the TKIP holdoff time (in violation of the spec) from 60 seconds to zero seconds:
aIOS: ap(config-if)#countermeasure tkip hold-time
WLC: config wlan security tkip hold-down
(this was implemented on the WLC in 4.1, via CSCsg56510)