Dies ist die Meldung, die Sie erhalten, wenn die AirPort-Karte / der AirPort-Treiber innerhalb von 60 Sekunden zwei TKIP- "MIChael" -MIC-Fehler (Message Integrity Check) erkennt oder vom AP über solche Fehler benachrichtigt wird.
Die TKIP-Verschlüsselung, die die Grundlage des ursprünglichen WPA darstellte und möglicherweise unter WPA2 im sogenannten "WPA2 Mixed Mode" noch aktiviert ist, hatte eine geringe Wahrscheinlichkeit für zufällige MIC-Ausfälle, zwei Ausfälle innerhalb von 60 Sekunden sind jedoch zu unwahrscheinlich Die WPA-Spezifikation behandelt es als Angriff und verlangt, dass das Netzwerk für ein oder zwei Minuten ausfällt, um Angreifer zu vereiteln.
Die AES-CCMP-Verschlüsselung, die die Basis von WPA2 ist, hat auch ein MIC (sie nennen es MAC - Message Authentication Check - es ist das 'M' von CCMP), aber ich erinnere mich nicht ganz Was soll passieren, wenn ein AES-CCMP-MAC-Fehler auftritt? Ich denke nicht, dass das Netzwerk vorübergehend heruntergefahren werden muss.
Bei weitem das wahrscheinlichste Szenario ist, dass Sie zufällig auf einen Fehler gestoßen sind, bei dem entweder der Zugriffspunkt oder der Client die MIC-Behandlung versaut haben oder der MIC-Fehlerbehandlungscode versehentlich ausgelöst wurde.
Ich habe gesehen, dass WLAN-Karten in diesem Bereich Fehler aufweisen, insbesondere im Promiscuous-Modus. Möglicherweise möchten Sie sicherstellen, dass Ihre WLAN-Karte nicht durch Parallels oder andere Aktionen in den Promiscuous-Modus versetzt wird. Führen Sie das ifconfig en1
Programm aus (wenn en1 wie gewohnt Ihre AirPort-Karte ist) und suchen Sie in der Liste der Schnittstellenflags ("UP, BROADCAST ...") nach dem PROMISC-Flag. Einige VM-Softwareprogramme verwenden den Promiscuous-Modus, um "Bridged" - oder "Shared" -Netzwerke zu aktivieren, zumindest für kabelgebundene Ethernet-Schnittstellen. Da viele Wireless-Karten den Promiscuous-Modus nicht gut beherrschen, achten die meisten modernen VM-Programme darauf, eine Wireless-Schnittstelle nicht in den Promiscuous-Modus zu versetzen.
Es ist möglich, aber unwahrscheinlich, dass sich jemand mit Ihnen herumgeschlagen hat, indem er einen 802.11-De-Auth-Frame mit dem entsprechenden Ursachencode gefälscht hat, den der Client dann pflichtbewusst über den Stack gemeldet hat.
Die mit Abstand am wenigsten wahrscheinliches Szenario ist , dass jemand tatsächlich war ein Angriff auf das Netzwerk zu starten.
Wenn das Problem erneut auftritt, ist eine 802.11-Überwachungsmodus-Paketverfolgung wahrscheinlich die beste Methode, um den Angriff aufzuzeichnen. Ich bin jedoch der Meinung, dass die Erläuterung einer guten 802.11-Überwachungsmodus-Paketverfolgung unter 10.5.8 den Rahmen dieser Antwort sprengt. Ich werde erwähnen, dass Sie /var/log/system.log
möglicherweise mehr darüber erfahren, was die AirPort Client- / Treibersoftware zu der Zeit sah, und dass Sie den Protokollierungsgrad ein wenig erhöhen können
sudo /usr/libexec/airportd -d
Snow Leopard bietet eine viel bessere AirPort-Debug-Protokollierung. Wenn Sie also auf Snow Leopard aktualisieren, lautet der Befehl:
sudo /usr/libexec/airportd debug +AllUserland +AllDriver +AllVendor
Snow Leopard schnüffelt ganz einfach:
sudo /usr/libexec/airportd en1 sniff 1
(In diesem Beispiel wird davon ausgegangen, dass Ihre AirPort-Karte "en1" ist und sich Ihr AP auf Kanal 1 befindet.)