Lieber Forumsteilnehmer !
Seit einiger Zeit beobachte ich auf einigen L-322 (8.00RU2) folgende Syslogmeldung:
Dec 9 10:46:33 rrzlc188 SYSTEM_ALERT: [WLAN-1] WLAN card 00:a0:57:16:85:8f (LANCOM 16:85:8f) [] hung (too many beacon transmit failures), resetting
Dec 9 10:46:35 rrzlc188 SYSTEM_ALERT: [WLAN-1] WLAN card 00:a0:57:16:85:8f (LANCOM 16:85:8f) [] hung (too many beacon transmit failures), resetting
Dec 9 10:46:36 rrzlc188 SYSTEM_ALERT: [WLAN-1] WLAN card 00:a0:57:16:85:8f (LANCOM 16:85:8f) [] hung (too many beacon transmit failures), resetting
Dec 9 10:46:38 rrzlc188 SYSTEM_ALERT: [WLAN-1] WLAN card 00:a0:57:16:85:8f (LANCOM 16:85:8f) [] hung (too many beacon transmit failures), resetting
Dec 9 10:46:40 rrzlc188 SYSTEM_ALERT: [WLAN-1] WLAN card 00:a0:57:16:85:8f (LANCOM 16:85:8f) [] hung (too many beacon transmit failures), resetting
Die Meldungen kommen im Sekundentakt und verschwinden erst wieder
nach einem Neustart des APs. Ein Aus/Einschalten des betroffenen WLAN-Moduls bringt nichts.
Was ist das Problem ? Hardwarefehler, Softwareproblem oder ein kaputter
Client in der Nähe des APs ?
Viele Grüße
Karl
L-322: WLAN hängt
Moderator: Lancom-Systems Moderatoren
Hallo,
der Fehler ist bei meinem L-321agn eben 15 mal innerhalb 5 Minuten aufgetreten, es war kein Client mit dem Access Point verbunden.
Auszug aus dem Gerätestatus:
Anzahl-Stationen: 0
Sendeleistung: 18 dBm
Rauschpegel: -95
Modem-Last: 2
Band: 2,4GHz
Radio-Modus: 11bgn-gemischt
Funk-Kanal: 13
Durchsatz: 2.6 KB
Gruß, Lothar
der Fehler ist bei meinem L-321agn eben 15 mal innerhalb 5 Minuten aufgetreten, es war kein Client mit dem Access Point verbunden.
Auszug aus dem Gerätestatus:
Anzahl-Stationen: 0
Sendeleistung: 18 dBm
Rauschpegel: -95
Modem-Last: 2
Band: 2,4GHz
Radio-Modus: 11bgn-gemischt
Funk-Kanal: 13
Durchsatz: 2.6 KB
Gruß, Lothar
Moin,
andere Leute machen auch über den Jahreswechsel Urlaub...nein, bisher nicht, das ganze
liegt erstmal bei Atheros. Irrgendwo klemmt's im Radioteil, aber den dokumentiert der
Chipsatz-Hersteller nicht wirklich...
Gruß Alfred
andere Leute machen auch über den Jahreswechsel Urlaub...nein, bisher nicht, das ganze
liegt erstmal bei Atheros. Irrgendwo klemmt's im Radioteil, aber den dokumentiert der
Chipsatz-Hersteller nicht wirklich...
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Hallo Alfred,alf29 hat geschrieben:...das ganze
liegt erstmal bei Atheros. Irrgendwo klemmt's im Radioteil, aber den dokumentiert der
Chipsatz-Hersteller nicht wirklich...
sowas ist mehr als ärgerlich und hoffe, dass ihr die Ursache finden bzw. beheben könnt.
Ist in der neuen Serie eins dieser Funkmodule verbaut?
AR9390
AR9392
Auf den jeweiligen Typ klicken, dann öffnet sich das entsprechende Datenblatt.
Grüße,
Lothar
Jepp, dann hänge ich mir hier auch mal mit ran:
Habe bei
2 * 1811n
3 * L-32x
das gleiche Problem. Sind alle in die RMA gewandert. Was ich noch nicht testen konnte ist ob die Geräte welche aus der RMA zurückkommen auch dieses Problem haben haben. Wir haben, damit die Kunden nicht ohne Gerät dastehen, die Ersatzgeräte beschafft und getauscht. Leider haben diese Geräte auch den gleichen Fehler.
Heute is das erste Gerät aus der RMA zurück, mal schauen ob der Fehler dort noch vorhanden ist.
Was ich bis jetzt feststellen konnte:
- Fehler tritt unter Last auf
- 2,4Ghz oder 5Ghz macht keinen Unterschied
- Diverse Einstellungen, Automatische Kanalwahl AN/AUS usw. macht keinen Unterschied
- Eine andere LANCOM-Antenne macht keinen Unterschied
Bei Kunden die das WLAN nur "so nebenbei" laufen lassen und keine Last erzeugen fällt der Bug nicht von Anfang an auf. Die ersten Beschwerden gab es als mal 500MB von einem lokalen Server auf das Laptop kopiert werden sollten. Dabei bricht, zumindest bei Win7, der Kopiervorgang auch nicht zwangsläufig ab. Die Unterbrechungen sind aber am unterbrochenen Ping und im SYSLOG mit der o.g. Meldung zu sehen.
Wie hier ja bereits geschrieben arbeitet LANCOM an dem Problem. Man teilte mir mit das noch nicht klar ist ob es an der Hardware oder Software liegt. Bis dahin warte ich mit dem Einbau der L-32x ersteinmal ab.
Habe bei
2 * 1811n
3 * L-32x
das gleiche Problem. Sind alle in die RMA gewandert. Was ich noch nicht testen konnte ist ob die Geräte welche aus der RMA zurückkommen auch dieses Problem haben haben. Wir haben, damit die Kunden nicht ohne Gerät dastehen, die Ersatzgeräte beschafft und getauscht. Leider haben diese Geräte auch den gleichen Fehler.
Heute is das erste Gerät aus der RMA zurück, mal schauen ob der Fehler dort noch vorhanden ist.
Was ich bis jetzt feststellen konnte:
- Fehler tritt unter Last auf
- 2,4Ghz oder 5Ghz macht keinen Unterschied
- Diverse Einstellungen, Automatische Kanalwahl AN/AUS usw. macht keinen Unterschied
- Eine andere LANCOM-Antenne macht keinen Unterschied
Bei Kunden die das WLAN nur "so nebenbei" laufen lassen und keine Last erzeugen fällt der Bug nicht von Anfang an auf. Die ersten Beschwerden gab es als mal 500MB von einem lokalen Server auf das Laptop kopiert werden sollten. Dabei bricht, zumindest bei Win7, der Kopiervorgang auch nicht zwangsläufig ab. Die Unterbrechungen sind aber am unterbrochenen Ping und im SYSLOG mit der o.g. Meldung zu sehen.
Wie hier ja bereits geschrieben arbeitet LANCOM an dem Problem. Man teilte mir mit das noch nicht klar ist ob es an der Hardware oder Software liegt. Bis dahin warte ich mit dem Einbau der L-32x ersteinmal ab.
Vermute eher einen Bug im Chipsatz, im Net sind mit etwas Suche diverse Infos zu finden.Djar hat geschrieben: Wie hier ja bereits geschrieben arbeitet LANCOM an dem Problem. Man teilte mir mit das noch nicht klar ist ob es an der Hardware oder Software liegt. Bis dahin warte ich mit dem Einbau der L-32x ersteinmal ab.
Es betrifft zwar nicht direkt den AR9280, möglich aber, dass auch dieser Chipsatz davon betroffen ist.
Werde mein Gerät nicht zurücksenden und abwarten was sich ergibt.
Die Funkmodule kann man austauschen und LCOS lässt sich mit Sicherheit auch auf andere Baugruppen anpassen.
Moin,
das Problem ist, daß diese Beacon-Sendefehler bei Atheros-Bausteinen (woanders
findet man häufig den Begriff 'beacon stuck'). ziemlich multi-kausal sind, Die Software
auf dem AP kann nur sehen, daß zu sendende Pakete (u.a. die regelmäßigen Beacons)
von der Hardware nicht verschickt werden - wo genau es im Pfad 'CPU->Hauptspeicher->
PCI(e)->WLAN-MAC->WLAN-Baseband->WLAN-Radio' klemmt, ist nur mit sehr aufwendigen
Einzeluntersuchungen und bisweilen mangels Doku der Hardware-Hersteller überhaupt
nicht zu analysieren, so daß man gezwungen ist, auf die 'große Keule' zurückzugreifen und
einmal den großen Reset-Knopf zu drücken (die Meldung im Log besagt letzten Endes
genau das).
Wir hatten z.B. vor ca. einem Jahr so einen Fall, bei dem sich herausstellte, daß in 11n-Chips
von Atheros die Krypto-Einheit abstürzt, wenn man ein Paket mit Null Byte Nutzdaten, also
auf dem Ethernet nur mit Quell/Zieladresse und Typ/Längen-Wort, sendet. Solche Pakete sind nicht
allzu häufig, in diesem Fall waren es bestimmte Spezial-Protokolle, wie sie z.B. im Industrie-
Umfeld anzutreffen sind. In einem 'normalen' Netz, wo außer TCP/IP nicht viel anderes
läuft, bekommt man dann erstmal so etwas nicht nachgestellt, bis man sich vom Kunden
eine Wireshark-Trace der Ethernet-Seite zeigen läßt und nach ein paar Stunden fällt dann
der Groschen. Man probiert's aus, kann das Problem nachstellen, fängt an, beim Hersteller
des WLAN-Chipsatzes nachzubohren und der gibt dann irgendwann zu, daß sie da ein
bestimmtes Errata haben, das sie auch nicht fixen wollen, 'weil sowas ja in normalen Netzen
nicht auftritt'. Also baut man in die Software einen Workaround ein...
Was ich eben in einem Absatz beschrieben habe, zieht sich häufig über Wochen bis
Monate hin, u.a. weil es so lange dauert, die Informationen von allen Beteiligten
zusammenzubekommen. Besonders unangenehm wird's, wenn etwas im Baseband oder
Radio des WLAN-Chipsatzes klemmt, denn dann kommt das Funkumfeld beim Kunden dazu,
das man als Entwickler weder messen noch nachstellen kann.
Die Änderung, die Lothar angesprochen hat, ist so ein Fall. Beim in den L-32x eingesetzten
Baustein stürzt der Baseband-Prozessor ab, wenn sich unter bestimmten Bedingungen
ein schwaches und ein starkes Signal auf dem Medium überlagern und man eine
bestimmte Option in der Hardware nicht deaktiviert hat. Das scheint zumindest die Probleme
der L-32x bei 2,4 GHz bei manchen Kunden einzudämmen, es hilft aber weder bei 5 GHz
noch bei anderen Chipsätzen. Das heißt nicht, daß wir die anderen Probleme nicht
ernst nehmen, aber solche 'Geistesblitze' schlagen leider eher stochastisch zu und niemand
kann so genau vorhersagen, bei wie vielen Kunden ein bestimmter Fix die Situation
verbessert. So wird man auf absehbare Zeit mit den Meldungen und der Reset-Keule leben
müssen, die Frage ist dann eher, wie häufig das passiert. Bestehende Assoziationen und
P2P-Verbindungen gehen nicht verloren, die Datenübertragung ist während der Zeit kurz
unterbrochen und es können Pakete verloren gehen. Wenn das im Minutentakt passiert,
ist das natürlich ein Problem, das abgestellt werden muß, aber selbst Atheros stellt sich auf
den Standpunkt, daß gelegentliche Resets in Ordnung wären und sie das immer schon so
gemacht haben. Nur stellt das nicht jeder AP-Hersteller so offen in seinen Logs zur Schau...
Gruß Alfred
das Problem ist, daß diese Beacon-Sendefehler bei Atheros-Bausteinen (woanders
findet man häufig den Begriff 'beacon stuck'). ziemlich multi-kausal sind, Die Software
auf dem AP kann nur sehen, daß zu sendende Pakete (u.a. die regelmäßigen Beacons)
von der Hardware nicht verschickt werden - wo genau es im Pfad 'CPU->Hauptspeicher->
PCI(e)->WLAN-MAC->WLAN-Baseband->WLAN-Radio' klemmt, ist nur mit sehr aufwendigen
Einzeluntersuchungen und bisweilen mangels Doku der Hardware-Hersteller überhaupt
nicht zu analysieren, so daß man gezwungen ist, auf die 'große Keule' zurückzugreifen und
einmal den großen Reset-Knopf zu drücken (die Meldung im Log besagt letzten Endes
genau das).
Wir hatten z.B. vor ca. einem Jahr so einen Fall, bei dem sich herausstellte, daß in 11n-Chips
von Atheros die Krypto-Einheit abstürzt, wenn man ein Paket mit Null Byte Nutzdaten, also
auf dem Ethernet nur mit Quell/Zieladresse und Typ/Längen-Wort, sendet. Solche Pakete sind nicht
allzu häufig, in diesem Fall waren es bestimmte Spezial-Protokolle, wie sie z.B. im Industrie-
Umfeld anzutreffen sind. In einem 'normalen' Netz, wo außer TCP/IP nicht viel anderes
läuft, bekommt man dann erstmal so etwas nicht nachgestellt, bis man sich vom Kunden
eine Wireshark-Trace der Ethernet-Seite zeigen läßt und nach ein paar Stunden fällt dann
der Groschen. Man probiert's aus, kann das Problem nachstellen, fängt an, beim Hersteller
des WLAN-Chipsatzes nachzubohren und der gibt dann irgendwann zu, daß sie da ein
bestimmtes Errata haben, das sie auch nicht fixen wollen, 'weil sowas ja in normalen Netzen
nicht auftritt'. Also baut man in die Software einen Workaround ein...
Was ich eben in einem Absatz beschrieben habe, zieht sich häufig über Wochen bis
Monate hin, u.a. weil es so lange dauert, die Informationen von allen Beteiligten
zusammenzubekommen. Besonders unangenehm wird's, wenn etwas im Baseband oder
Radio des WLAN-Chipsatzes klemmt, denn dann kommt das Funkumfeld beim Kunden dazu,
das man als Entwickler weder messen noch nachstellen kann.
Die Änderung, die Lothar angesprochen hat, ist so ein Fall. Beim in den L-32x eingesetzten
Baustein stürzt der Baseband-Prozessor ab, wenn sich unter bestimmten Bedingungen
ein schwaches und ein starkes Signal auf dem Medium überlagern und man eine
bestimmte Option in der Hardware nicht deaktiviert hat. Das scheint zumindest die Probleme
der L-32x bei 2,4 GHz bei manchen Kunden einzudämmen, es hilft aber weder bei 5 GHz
noch bei anderen Chipsätzen. Das heißt nicht, daß wir die anderen Probleme nicht
ernst nehmen, aber solche 'Geistesblitze' schlagen leider eher stochastisch zu und niemand
kann so genau vorhersagen, bei wie vielen Kunden ein bestimmter Fix die Situation
verbessert. So wird man auf absehbare Zeit mit den Meldungen und der Reset-Keule leben
müssen, die Frage ist dann eher, wie häufig das passiert. Bestehende Assoziationen und
P2P-Verbindungen gehen nicht verloren, die Datenübertragung ist während der Zeit kurz
unterbrochen und es können Pakete verloren gehen. Wenn das im Minutentakt passiert,
ist das natürlich ein Problem, das abgestellt werden muß, aber selbst Atheros stellt sich auf
den Standpunkt, daß gelegentliche Resets in Ordnung wären und sie das immer schon so
gemacht haben. Nur stellt das nicht jeder AP-Hersteller so offen in seinen Logs zur Schau...
Gruß Alfred