Hallo - Problem mit einem L54G - ich verstehe den Zusammenhang absolut nicht. Der L54G lief bis gestern asolut stabil - BIS:
Ein Windows- Mobile Gerät "HTC StrTrk" wurde per ActiveSync 4.2 an ein per WPA-PSK verbundenes Notebook angeschlossen. Danach war das gesamte WiFi Netz lahm gelegt, kein Notebook konnte mehr per L54G kommunizieren. Ich suche nach einem Zusammenhang - doch der ist mir bis jetzt völlig fremd.
Ein WM5 Gerät nutzt per Active Sync ein RNDIS Device als Netzwerkbrücke via USB und wird auch im Netzwerk sichtbar mit eigener IP.
Stecker raus - rein - ActiveSync Notebook neu gestartet - dann ging's wieder...
So - Kiwi installiert und -> Mal ausprobiert.
Erst ohne Verschlüsselung synchronisiert - kein Problem
Dann mit WEP - kein Problem
Dann mit WPA PSK - RUMMS.
Das witzige dabei: Alle anderen Windows Mobile 5 Geräte können ohne Probleme synchronisieren.
Siehe Syslog wie unten - dann war's vorbei:
2006-06-26 19:30:53 Auth.Notice 192.168.0.253 CONN-LOGIN_INFO: [WLAN-1-4] Disassociated WLAN station 00:0e:35:a0:6f:b6 (Intel a0:6f:b6) [NB-SAE-VAIOA297] due to station request (Unspecified Reason)<000>
2006-06-26 19:30:53 Auth.Notice 192.168.0.253 CONN-LOGIN_INFO: [WLAN-1] Associated WLAN station 00:0e:35:a0:6f:b6 (Intel a0:6f:b6) [NB-SAE-VAIOA297]<000>
2006-06-26 19:30:54 Auth.Notice 192.168.0.253 CONN-LOGIN_INFO: [WLAN-1] Determined IP address for station 00:0e:35:a0:6f:b6 (Intel a0:6f:b6) [NB-SAE-VAIOA297]: 192.168.0.22<000>
2006-06-26 19:32:00 Auth.Notice 192.168.0.253 CONN-LOGIN_INFO: [WLAN-1] Disassociated WLAN station 00:0e:35:a0:6f:b6 (Intel a0:6f:b6) [NB-SAE-VAIOA297] due to station request (Unspecified Reason)<000>
2006-06-26 19:32:00 Kernel.Notice 192.168.0.253 SYSTEM_INFO: [WLAN-1-2] WLAN blacklist action on 00:0e:35:a0:6f:b6 (Intel a0:6f:b6) [Disabling short preamble for Intel Centrino(tm) clients]<000>
2006-06-26 19:32:00 Auth.Notice 192.168.0.253 CONN-LOGIN_INFO: [WLAN-1-2] Associated WLAN station 00:0e:35:a0:6f:b6 (Intel a0:6f:b6) [NB-SAE-VAIOA297]<000>
2006-06-26 19:32:01 Auth.Notice 192.168.0.253 CONN-LOGIN_INFO: [WLAN-1-2] Key handshake with peer 00:0e:35:a0:6f:b6 (Intel a0:6f:b6) successfully completed<000>
2006-06-26 19:32:01 Auth.Notice 192.168.0.253 CONN-LOGIN_INFO: [WLAN-1-2] Determined IP address for station 00:0e:35:a0:6f:b6 (Intel a0:6f:b6) [NB-SAE-VAIOA297]: 192.168.0.22<000>
2006-06-26 19:32:03 Auth.Alert 192.168.0.253 CONN-LOGIN_ALERT: [WLAN-1-2] TKIP Michael failure communicating with partner 00:0e:35:a0:6f:b6 (Intel a0:6f:b6) [NB-SAE-VAIOA297]<000>
2006-06-26 19:32:03 Auth.Alert 192.168.0.253 CONN-LOGIN_ALERT: [WLAN-1-2] TKIP Michael failure communicating with partner 00:0e:35:a0:6f:b6 (Intel a0:6f:b6) [NB-SAE-VAIOA297]<000>
TKIP -> Michael failure?
Moderator: Lancom-Systems Moderatoren
TKIP -> Michael failure?
Cheers,
Joe
Joe
Moin,
Michael ist die Message-Integritätsprüfung, die bei TKIP verwendet wird. So ein Fehler
tritt auf, wenn ein Paket entschlüsselt werden konnte, die Prüfsumme der Klartextdaten
danach aber nicht mehr stimmt. Wenn mehr als ein solcher Fehler pro Minute auftritt, ist
vorgeschrieben, daß der AP die Funkzelle für eine Minute abschaltet und danach komplett
neues Schlüsselmaterial verwendet, da davon ausgegangen werden muß, daß gerade ein
Angriff auf das Funknetz stattfindet und die Michael-Prüfung nur noch eine relativ geringe
Hürde darstellt.
Solche Michael-Fehler können sowohl vom AP beim Paketempfang erkannt als auch von
einem eingebuchten Client an den AP gemeldet werden. Neben einem Angriff auf das
Funknetz kämen noch Implmementierungsfehler in der Software in Frage. Da die mir bei
LANCOMs bezüglich TKIP/Michael aber noch nie über den Weg gelaufen sind (die
Atheros-Chips erledigen das in Hardware, da kann nicht viel schief gehen), tippe ich eher
auf einen Client, der eine Macke hat. Sind die Centrino-Treiber einigermaßen neu?
Gruß Alfred
Michael ist die Message-Integritätsprüfung, die bei TKIP verwendet wird. So ein Fehler
tritt auf, wenn ein Paket entschlüsselt werden konnte, die Prüfsumme der Klartextdaten
danach aber nicht mehr stimmt. Wenn mehr als ein solcher Fehler pro Minute auftritt, ist
vorgeschrieben, daß der AP die Funkzelle für eine Minute abschaltet und danach komplett
neues Schlüsselmaterial verwendet, da davon ausgegangen werden muß, daß gerade ein
Angriff auf das Funknetz stattfindet und die Michael-Prüfung nur noch eine relativ geringe
Hürde darstellt.
Solche Michael-Fehler können sowohl vom AP beim Paketempfang erkannt als auch von
einem eingebuchten Client an den AP gemeldet werden. Neben einem Angriff auf das
Funknetz kämen noch Implmementierungsfehler in der Software in Frage. Da die mir bei
LANCOMs bezüglich TKIP/Michael aber noch nie über den Weg gelaufen sind (die
Atheros-Chips erledigen das in Hardware, da kann nicht viel schief gehen), tippe ich eher
auf einen Client, der eine Macke hat. Sind die Centrino-Treiber einigermaßen neu?
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Moin,
danke- Deine Erklärung macht Sinn und ist verständlich für mich. Die Geräte sind leider nicht meine - ich habe das Problem gestern bei einem lieben Freund beobachtet. Dumm, dass ich nicht eher dahinter gekommen bin, dort einen Syslog aufzusetzen.
Bei näherer Betrachtung:
Problem:
-> Ich schließe hier den Fehler seitens Lancom aus.
-> Ich kenne eingesetzte Softwarekonfigurationen auf dem Client nicht.
Das erste Notebook ist ein VaioA297a, welches mit den (damals) mitgelieferten Treibern läuft - sie dürften alles andere als aktuell sein. Das zweite ist ein relativ neues Vaio TX1HP (2-3 Monate, die WiFi Treiber sollten relativ aktuell sein).
Die Funktion des AP ist mir neu und erscheint mir sinnvoll. Ich denke, ich sollte am WiFi- Treiber des Notebooks ansetzen, was sich allerdings durch die in den Stack/ Sock eingreifende, bereits installierte Software relativ schwierig gestaltet - dazu kommt mein Hasskandidat - Option UMTS Treiber.
Ich denke, Letzeres unterstreicht Deine Ausführung.
Meine Lage ist momentan aussichtslos.
danke- Deine Erklärung macht Sinn und ist verständlich für mich. Die Geräte sind leider nicht meine - ich habe das Problem gestern bei einem lieben Freund beobachtet. Dumm, dass ich nicht eher dahinter gekommen bin, dort einen Syslog aufzusetzen.
Bei näherer Betrachtung:
Problem:
-> Ich schließe hier den Fehler seitens Lancom aus.
-> Ich kenne eingesetzte Softwarekonfigurationen auf dem Client nicht.
Das erste Notebook ist ein VaioA297a, welches mit den (damals) mitgelieferten Treibern läuft - sie dürften alles andere als aktuell sein. Das zweite ist ein relativ neues Vaio TX1HP (2-3 Monate, die WiFi Treiber sollten relativ aktuell sein).
Die Funktion des AP ist mir neu und erscheint mir sinnvoll. Ich denke, ich sollte am WiFi- Treiber des Notebooks ansetzen, was sich allerdings durch die in den Stack/ Sock eingreifende, bereits installierte Software relativ schwierig gestaltet - dazu kommt mein Hasskandidat - Option UMTS Treiber.
Ich denke, Letzeres unterstreicht Deine Ausführung.
Meine Lage ist momentan aussichtslos.
Zuletzt geändert von joeMJ am 27 Jun 2006, 18:54, insgesamt 1-mal geändert.
Cheers,
Joe
Joe
PENG!
Na herzlichen Dank!
http://groups.google.de/group/microsoft ... 3ddc15cb86 / http://www.mobilejoe.de/joeforums/showt ... post111096
Zeit für 'ne Bugmeldung.
Thema für Lancom erledigt...
http://groups.google.de/group/microsoft ... 3ddc15cb86 / http://www.mobilejoe.de/joeforums/showt ... post111096
Zeit für 'ne Bugmeldung.
Thema für Lancom erledigt...
Cheers,
Joe
Joe
Hallo,
wir sind jetzt auch opfer dieses problemes mit dem TKIP Michael failure geworden und da ich nicht so recht weiter weis hole ich diesen thread mal nach oben.
also wir haben 2 L-54ag mit 23 clients am laufen 1x10 und 1x13 und in letzter zeit ist uns im lanmon aufgefallen das alle clients disconnectet werden und auch das wlan modul ein rotes kreuz bekommt. nach einer knappen minute haben sich alle wieder eingebucht. da wir anfänglich von einem defekt ausgegangen sind haben wir einen lancom ausgetauscht doch der fehler blieb bestehen und taucht in unterschiedlichen zeitabständen (manchmal nur einmal in 2h aber auch mal 3mal innerhalb 15min) auf. nach einem wlan trace im telnet ist uns nun kurz vor dem disconnect auch ein tkip michael failure von einem client aufgefallen.
nur wenn ich das hier im thread richtig verstanden haben kommt es zu dem fehler nur wenn ein pc o. nb client mit active sync beteiligt ist ? unsere clients sind aber keine pc-systeme direkt sonder nur Linksys WRT-54GL u. Buffalo WHR-G54S / WHR-HP-G54 mit DD-WRT drauf.
und da es auf beiden L-54ag passiert ist es mit sichherheit auch nicht nur ein bestimmter client der den fehler verursacht.
daher nun meine frage ans forum durch was kann der michael failure noch verursacht werden oder ist das nur ein zufall und wir haben doch ein gänzlich anderes problem?
Greetings
VeC
wir sind jetzt auch opfer dieses problemes mit dem TKIP Michael failure geworden und da ich nicht so recht weiter weis hole ich diesen thread mal nach oben.
also wir haben 2 L-54ag mit 23 clients am laufen 1x10 und 1x13 und in letzter zeit ist uns im lanmon aufgefallen das alle clients disconnectet werden und auch das wlan modul ein rotes kreuz bekommt. nach einer knappen minute haben sich alle wieder eingebucht. da wir anfänglich von einem defekt ausgegangen sind haben wir einen lancom ausgetauscht doch der fehler blieb bestehen und taucht in unterschiedlichen zeitabständen (manchmal nur einmal in 2h aber auch mal 3mal innerhalb 15min) auf. nach einem wlan trace im telnet ist uns nun kurz vor dem disconnect auch ein tkip michael failure von einem client aufgefallen.
nur wenn ich das hier im thread richtig verstanden haben kommt es zu dem fehler nur wenn ein pc o. nb client mit active sync beteiligt ist ? unsere clients sind aber keine pc-systeme direkt sonder nur Linksys WRT-54GL u. Buffalo WHR-G54S / WHR-HP-G54 mit DD-WRT drauf.
und da es auf beiden L-54ag passiert ist es mit sichherheit auch nicht nur ein bestimmter client der den fehler verursacht.
daher nun meine frage ans forum durch was kann der michael failure noch verursacht werden oder ist das nur ein zufall und wir haben doch ein gänzlich anderes problem?
Greetings
VeC