Regarding comment #7: The AP did not detect Michael MIC failure in that case at May 26 13:10:02; only one of the associated stations did. As such, this by itself should not trigger TKIP countermeasures. In fact, the AP would not be detecting Michael MIC failures in this kind of setup if all the associated stations were using CCMP as pairwise cipher since the AP would not be receiving any TKIP frames.
Since none of the other associated stations reported the failure and the timing of the error report matches with reassociation, I would assume something goes wrong with TKIP group key configuration at the station that reported the failure. As far as wpa_supplicant is concerned, the actual failure detection event comes from the driver and wpa_supplicant is only forwarding it to the AP. Are all the failures similar? I.e., are they only reported immediately after a disassociation-reassociation sequence? The AP seems to be configured to rekey the TKIP group key whenever a station disconnects and that may be the key trigger for the behavior here. Would it be possible to get more verbose wpa_supplicant debug log from a station that reports the Michael MIC failure? I would like to see both the previous association and EAPOL handshakes and the sequence of EAPOL frames and events from wpa_supplicant during the disassociation- reassociation-failure report sequence. -- 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
