Guest
[Entry]
"That's the message you get when the AirPort card/driver detects two TKIP ""MIChael"" MIC (Message Integrity Check) failures within 60 seconds, or is notified of such failures by the AP.
TKIP encryption, which was the basis of original WPA and may still be enabled under WPA2 in what's known as ""WPA2 Mixed Mode"", had a tiny likelihood of random MIC failures, but two failures within 60 seconds is too unlikely to be randomness, so the WPA spec treats it as an attack, and requires the network to go down for a minute or two to thwart attackers.
The AES-CCMP encryption that is the basis of WPA2 also has a MIC (well, they call it a MAC -- Message Authentication Check -- it's the 'M' of CCMP), but I don't recall off the top of my head what's supposed to happen if there's an AES-CCMP MAC failure. I don't think it involves downing the network temporarily though.
By far the most likely scenario is that you just happened to hit some bug where either the AP or the client screwed up its MIC handling, or where the MIC-failure-handling code got accidentally triggered.
I've seen wireless cards have bugs in this area, especially running in promiscuous mode. You might want to make sure that Parallels or something else isn't putting your wireless card into promiscuous mode. Run ifconfig en1 (if en1 is your AirPort card, as it typically is) and look in the interface flag list (""UP,BROADCAST..."") for the PROMISC flag. Some VM software uses Promiscuous mode to enable ""bridged"" or ""shared"" networking, at least for wired Ethernet interfaces. Because many wireless cards don't handle promiscuous mode well, most modern VM software is careful not to put a wireless interface into promiscuous mode.
It's possible, but unlikely, that someone was messing with you by forging an 802.11 de-auth frame with the relevant reason code, which the client then dutifully reported up the stack.
By far the least likely scenario is that someone was actually launching an attack on your network.
If the problem happens again, an 802.11 monitor-mode packet trace is probably the best way to record the attack. But I feel that explaining how to do a good 802.11 monitor-mode packet trace under 10.5.8 is beyond the scope of this answer. I will mention that /var/log/system.log might tell you more about what the AirPort client/driver software saw at the time, and you can increase the log level a bit with
sudo /usr/libexec/airportd -d
Snow Leopard has much better AirPort debug logging, so if you upgrade to Snow Leopard, the command is:
sudo /usr/libexec/airportd debug +AllUserland +AllDriver +AllVendor
Sniffing is easy on Snow Leopard:
sudo /usr/libexec/airportd en1 sniff 1
(That example assumes your AirPort card is en1, and your AP is on channel 1.)"
|
