Thanks, Jouni. I see you're correct regarding the countermeasures not being triggered in that log.
There are actually two different scenarios that may or may not be related: the MIC failures when multiple stations are associated within a tight window, and the periodic MIC failures when stations are connected for long periods of time (which may increase in frequency with an increase in clients). The AP log from comment #7 is an example of the second scenario, and looking at last night's run, we're coming up on 15.5 hours with three MIC failures and no countermeasures triggered. Here's a snippet from the AP log from the first scenario (tight window association): May 26 16:00:15 Severity:5 Associated with station 1c:4b:d6:a3:75:60 May 26 16:00:15 Severity:5 Installed unicast CCMP key for supplicant 1c:4b:d6:a3:75:60 May 26 16:00:16 Severity:5 Associated with station 1c:4b:d6:55:e8:01 May 26 16:00:16 Severity:5 Installed unicast CCMP key for supplicant 1c:4b:d6:55:e8:01 May 26 16:00:16 Severity:1 MIC integrity error (reported from STA) src_addr=1c:4b:d6:55:e8:01 May 26 16:00:16 Severity:5 Disassociated with station 1c:4b:d6:55:e8:01 May 26 16:00:17 Severity:5 Rotated TKIP group key. May 26 16:00:20 Severity:5 Deauthenticating with station 1c:4b:d6:55:e8:01 (reserved 2). May 26 16:00:20 Severity:5 Disassociated with station 1c:4b:d6:55:e8:01 May 26 16:00:23 Severity:5 Associated with station 1c:4b:d6:55:ef:bf May 26 16:00:23 Severity:5 Installed unicast CCMP key for supplicant 1c:4b:d6:55:ef:bf May 26 16:00:23 Severity:1 MIC integrity error (reported from STA) src_addr=1c:4b:d6:55:ef:bf May 26 16:00:23 Severity:1 Start TKIP countermeasures mode. May 26 16:00:23 Severity:5 Deauthenticating with station 1c:4b:d6:55:ef:bf (reserved 14). May 26 16:00:23 Severity:5 Deauthenticating with station 1c:4b:d6:a3:75:60 (reserved 14). May 26 16:00:23 Severity:5 Disassociated with station 1c:4b:d6:55:ef:bf May 26 16:00:23 Severity:5 Disassociated with station 1c:4b:d6:a3:75:60 May 26 16:00:23 Severity:5 Rotated TKIP group key. May 26 16:01:23 Severity:1 End TKIP countermeasures mode. I think especially if you look at 1c:4b:d6:55:ef:bf, you'll see the CCMP pairwise key for the station, but the group key is clearly still TKIP, and as you noted the TKIP group key seems to be rotated whenever a station comes and goes. But the station can still screw up the group key rotation and trigger the TKIP countermeasures. We're seeing this behavior on our Cisco APs as well, but the Apple AirPort is handy for the test. I believe all the failures are similar and that the variance we've seen has to do only with the number of stations. The population suffers from random disassociation/reassociation (either the no probe response or the MIC failure), which then triggers a group rekey, which increases the odds of another random disassociation/reassociation in another member of the population. Someone with better math than me could probably work out how this plays out as the population increases, but we've seen it's pretty painful in groups of 30. I'll jump on the wpa_supplicant debug verbosity right now. -- ath9k module causing MIC challenge failures https://bugs.launchpad.net/bugs/580753 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
