Ok, hab dich nicht vergessen
.
Das Problem scheint nur wesentlich komplizierter zu sein und es gibt noch keine wirklichen Lösungsansätze.
Betroffen von so einem Freeze sind AirportExtreme Firmware 5.7(Ufo) und AirportExpress. Wohingegen für die Extreme ein temporärer workaround existiert in dem man auf Firmware 5.5.1 zurückgeht, gibt es sowas nicht für die Express.
Die aktuelle Firmwareversion 6.3 (Jan.06) sollte unter anderem eben auch einen Fehler beheben, bei dem durch manipulierte Pakete die Station abgeschossen werden konnte.
Wahrscheinlich gibt es aber eben noch weitere Szenarien die solch einen Absturz verursachen.
Mittlerweile hab ich selbst mal ein Testnetzwerk aufgesetzt um, mein eigentliches nicht permanent zu killen :-D .
Dazu hab ich mir einen Panasonic mit IntelProWireless 2915abg Chip und XP sowie einen D-Link DWL122 (Win2000) ins Netz geholt.
Mein eigentliches Netz ist als WDS mit WPA zusammengesetzt (Extreme und Express) das Testnetz mit einer Express hab ich versucht deinem anzugleichen und mit WEP verschlüsselt, beide Netze verteilen Adressen via DHCP. Um es vorweg zu nehmen der Freeze tritt unabhängig von WPA(TKIP) oder WEP auf. Ansonsten frieren die Stationen auch nur ein wenn der Client sich auch versucht hat an einer Station anzumelden/abzumelden(?), d.h. für den Fall des WDS das eine abgeschmierte Station nicht automatisch andere im WDS mit hinterherzieht, die betroffene Station bleibt einfach stehen, nur wenn der auslösende Client mehrere Stationen in seinem Wirkungskreis erreichen kann wird er sie gegf. ebenfalls abschießen.
Unter welchen Umständen das Abschießen jedoch genau passiert konnte ich noch nicht herausfinden.
Es tritt aber bisweilen nur über WLAN auf, über Ethernet angebunde Clients konnten bisher die Station nicht aus dem Tritt bringen. Desweiteren konnte ich feststellen das der Fehler bei mir lediglich bei einem Verbindungsversuch/-abbruch auftritt, jedoch lässt es sich für mich momentan noch nicht reproduzieren.
In einem Fall lebte die WEP-Teststation nur ganze 2 Stunden bis sie sich aufhing. Momentan läuft sie seit fast drei Tagen ohne Hänger... arghh
.
Am häufigsten tritt der Fehler mit Windowsclients auf, in einem Mac-Only Netz trat der Fehler bisher nicht auf (im Internet finden sich nur sehr wenige Berichte wo dieses Szenario auch mit Macclients auftreten soll).
Mit WireShark (etheral) konnte ich feststellen das die eingefrorenen Stationen immernoch ihr Leuchtfeuer aussenden (Beacon), was auch erklärt das man, nachdem die Station sich aufgehangen hat, noch mit dem Netz verbunden ist.
Das bedeutet das auf den unteren Leveln die Software noch halbwegs funktioniert und weiter oben in der Anwendungsschicht etwas hängt. Zu diesem Zeitpunkt akzeptiert die Station keine weiteren WLAN-Clients mehr und sie ist auch über Ethernet nicht mehr mit AirportAdmin bzw. Management ansprechbar, SNMP-Abfragen funktionieren auch nicht mehr.
Wahrscheinlich tappt Apple selbst auch noch im Dunkeln, bekannt sein dürfte dort das Problem aber, da eben auch die Extreme (Ufo) davon betroffen ist die häufig auch z.B. als PoE-Variante in größerer Anzahl installiert wurde und für diese Stationen, wie gesagt, als workaround ein herunterstufen der Firmware empfohlen wird. ->
Link
Nungut das hilft deiner Express jetzt auf die Schnelle erstmal nicht, ich hab aber mal deine Logdatei durchgeschaut um sie mit meinen hier zu vergleichen.
Es stehen noch ein paar Optionen offen, die probiert werden können um den Fehler einzukreisen :-D !
Also aus deinen zwei Logs lässt sich erstmal folgendes lesen.
In deinem Netz konnte ich 8 verschiedene Clients zählen, anhand der ersten sechs Stellen der MAC-Adresse erkennt man welcher Hersteller hinter dem WLAN-Chip bei den Clients hängt.
0014a5 - Gemtek
0014a4 - HonHaiPrecision
000e35 - Intel
001124 - Apple (das scheinst dann du zu sein)
0013ce - Intel
001500 - Intel
000cf6 - SiteCom Europe
00904b - Gemtek
In deinem Log treten jetzt ein Haufen von Meldungen auf, diese sind wie ich herausgefunden habe nicht weiter kritisch. Der Großteil stammt aus der Protokollstufe 5 die bedeutet "Hinweise" und sind auch nur als solche zu interpretieren.
Das Protokoll ist in 8 Stufen eingeteilt wobei die 0 die kritischsten Fehler aufzeigt und die 7 jeden sinnlosen Text mit überliefert. Auf der Stufe 5 werden solche Mitteilungen übermittelt ob ein Client verbunden (Associated) oder nicht verbunden (Disassociated) ist, diese Werte stehen da wenn sie durch den Client provoziert wurden. Deauthenticated (frei übersetzt: herauswerfen) wird meist von der Station eingeleitet, diese wirft einen Client nach einer bestimmten Zeit in der er sich nicht gemeldet hat raus, meist steht dann in Klammern noch der Grund (inactivity).
Da viele Windowsclients eine Art Ruhezustand(?) des WLAN-Adapters unterstützen, den vermtl. die Airportstation nicht kennt, kommt es dann teilweise zu dieser Meldung:
Deauthenticated with ... (received invalid class-3 frame).
Das scheint eine Art Quittung auf die Antwort des WLAN-Clients (sta) zu sein mit dem Hinweis das die Station irgendetwas nicht versteht und als unzulässig (invalid) deklariert.
Dies sollte den Client veranlassen sich erneut mit der Station zu verbinden (Re-associated oder associated).
Meldet sich der Client nicht auf Deauthenticated wird er auf Stufe 1 zurückgestellt und aus der Verbundenen-Liste der Station entfernt.
Bei WLAN gibt es, soweit ich das verstanden habe, 3 Rahmen (Frame) mit möglichen Befehlen für den Aufbau und Abbau einer Verbindung und dem Datenaustausch.
Hier, für Interessenten (Seite 14) die 3 Frametypen und deren Funktion ->
Link
Die Bad pre-shared key Meldungen sind mir bisher nur bei Mac-Clients aufgefallen, warum dies so ist weiß ich noch nicht genau, vermtl. versucht der Mac sich mit einem falschen oder gar keinem Schlüssel anzumelden, weswegen man manchmal nicht mit dem Netz verbunden wird und es erneut versuchen muss, was dann aber meist klappt.
Den Log zu lesen macht auf jeden Fall Spass, da die Clients hier offensichtlich die kleine Express gut beschäftigen.
Bei einigen Clients fallen mir aber schon merkwürdige Verhaltensweisen auf.
Das ist zum einen die 0013ce (Intel), die innerhalb einer Stunde ein wahres Feuerwerk los lässt, das könnte vielleicht daran liegen das dieser Client häufig in den Ruhezustand geht. Dieser Client ist im Schnitt nur 2-4min ohne Geschimpfe verbunden.
Zum anderen ist es die 000e35 (Intel), die hier zwar selten am Platze ist aber sehr schnell hintereinander sich verbindet und wieder trennt bis sie letztlich Ruhe gibt und die Verbindung hält.
Die 0014a4 (HonHai) und 0014a5(Gemtek) sind sehr häufig hier vertreten, scheinen aber ein normales Verhalten aufzuweisen.
Die invaliden class-3 Frames kommen, so wie ich es bei mir testen konnte durch eine Art Ruhezustand des WLAN-Adapters zustande, ist die Karte auf höchste Leistung bzw. Energiesparen deaktiviert kommt es auch nicht zu solchen Meldungen.
Wenn du also die Möglichkeit hast, das die Teilnehmer des WLANs testweise diesen Energiesparzustand des Adapters deaktivieren bzw. manuell auf höchste Leistung setzen könnten, würde das helfen herauszufinden ob der Fehler der Station aus dieser Richtung kommt, also durch das häufige ein- und ausbuchen der Clients durch wach/schlaf/wach/schlaf.... In der Regel lassen sich die Einstellungen des WLAN-Adapters bei Windows über den Gerätemanager -> Netzwerkkarten -> entsprechendesModul mit einem Rechtsklick und Eigenschaften erreichen, dort gibt es bei den meisten Adaptern einen Reiter "Erweitert" wo sich die auch Energieeinstellung des WLAN-Adapters befindet.
Dieser Vorgang ist natürlich keine Dauerlösung, sondern dient lediglich zur Einkreisung des Problems und verändert dabei weniger am System als neue Treiber und Gedöns zu installieren.
Eine andere Frage die ich momentan noch nicht beantworten kann, tritt das Problem auch bei einem unverschlüsselten Netz auf? Ich vermute fast ja, da ich denke das der Fehler während des An- oder Abmeldevorgangs auftritt.
Was du aber bevor alle Windowsrechner manipuliert werden
noch machen kannst ist das Netz auf nur b einzustellen und nicht b/g kompatibel.
Benutzt ihr die Airtunesfunktion der Station?
Ist euer WLAN das einzigste in der Umgebung oder sehen die Windowsrechner evtl. noch andere Netze in ihrer Umgebung mit denen sie kommunizieren könnten, egal ob verschlüsselt oder offen?
Gibt es sonst irgendwelche Auffälligkeiten bei diesem Netz, z.B. das Rechner die Verbindung verlieren oder Probleme haben sich zu verbinden?
So, ma schauen ob mein Text dein Protokoll schont überholt hat ...
nee, noch nich ganz :-D
Zumindest hat deine Station, anhand des Logs zu erkennen, schon mal einen ganzen Tag jetzt überlebt.
Ich versuch mal Meine noch weiter fleißig zum Abstürzen zu bewegen um zu ergründen wodurch die AirportStation vor Schreck erstarrt.
