Background-Scan und "too many beacon transmission misse

thomasgiger · Beitrag von **thomasgiger** » 25 Mai 2009, 14:05

Es war mir zwar schon in früheren LCOS Versionen aufgefallen, dass bei eingeschaltetem Background Scan immer wieder mal alle Clients eines AP reassoziiert werden, verbunden mit einem kurzen Abriss des Datenflusses, aber erst in jüngeren OS-Versionen gibt es dazu die passende Log-Mitteilung:

hung (too many beacon transmission misses), resetting

Wenn man das Zeitintervall höher wählt - sagen wir mal 3600 Sekunden - dann passiert es nicht sehr häufig aber doch immerhin so alle 10 Tage. Ergo schalten wir den Background-Scan ab, obwohl der schon recht hübsch wäre, wenn er nicht diese Nebenwirkung hätte.

Nun haben wir an einer Stelle eine P2P-Verbindung installiert, allerdings erst mal nur eine Seite. Weil's noch ein wenig bis zur Montage der Gegenstelle dauern wird, habe ich mal spaßeshalber den Background-Scan mit 120 Sekunden aktiviert ... der AP bringt die obige Meldung nun so alle 3 bis 12 Stunden, obwohl da nicht mal ein Link zur Gegenstelle existiert. Dass es zu viele Clients wären oder einfach viel Traffic, kann man also ausschließen.

Das widerspricht zwar nicht den bisherigen Erfahrungen, aber ich frage mich halt doch, warum die Beacons eigentlich mit dem Background-Scan kollidieren müssen ... und frage hier einfach mal

alf29 · Beitrag von **alf29** » 25 Mai 2009, 14:44

Moin,

da waren im Zusammenhang mit dem Wiederaufsetzen der
TSF nach einem Background-Scan noch einige Sachen
verkehrt, weshalb diese Meldung zuschlug. Ob der Support
auf Anfrage eine 7.68 herausrückt, bei der ich dahingehend
einige Sachen behoben habe, weiß ich nicht.

Gruß Alfred

thomasgiger · Beitrag von **thomasgiger** » 27 Mai 2009, 13:08

Vielen Dank für den Fix - so wichtig, dass wir eine Vorabversion brauchen, ist es ja nicht. Aber ich freue mich, dass der Background Scan in einer zukünftigen Version wieder praktisch nutzbar sein wird. Es gab nämlich schon Pläne, ein einzelnes LANCOM mit einer Omni als "dedizierten Scanner" an den Stationen einzusetzen

thomasgiger · Beitrag von **thomasgiger** » 23 Aug 2009, 03:08

Habe jetzt auf diesem L310 (PtP Link ohne Gegenstelle zur Zeit) die neue 7.70Rel (build 100) aufgespielt und leider ist das Verhalten unverändert: von Zeit zu Zeit gibt es ein "WLAN card ... [] hung (too many beacon transmit failures), resetting".

alf29 · Beitrag von **alf29** » 23 Aug 2009, 09:16

Moin,

vorsicht, Falle, 'transmit misses' und 'transmit failures' sind nicht das gleiche. Ersteres meint, daß
der Treiber meint, den Sendezeitpunkt verpaßt zu haben, letzteres bedeutet, daß die Hardware
das Beacon nicht verschickt hat, üblicherweise weil der Rausch/Störpegel zu hoch gelegen hat.
Dieser Effekt sollte in der 7.70 durch eine Mittlung der Rauschpegel-Messung deutlich seltener
auftreten, je nach Situation kann er jetzt aber auch etwas öfter passieren. Neu ist der Effekt
nicht und auch nicht auf 11n-Geräte beschränkt, bei älteren Firmwaren gab es dafür nur keinen
Eintrag im Log...das ganze ist durch die Arbeitsweise der Atheros-Chips bedingt unf läßt sich
nicht zu 100% verhindern.

Gruß Alfred

thomasgiger · Beitrag von **thomasgiger** » 16 Sep 2009, 13:11

Sorry, dass ich dieses Thema wieder aufgreife, aber in der Zwischenzeit habe ich Langzeitversuche angestellt, und die zeigen:

1) Es gibt sowohl 'misses' wie auch 'failures'. Der Rauschpegel ist nicht mal so hoch (-94 dBm), aber an der Modemlast im Leerlauf (es gibt ja noch keine Gegenstelle in dieser P2P Verbindung) erkennt man, dass da "etwas" sein muss.

2) Wie auch immer: wenn ich den Background Scan abschalte, gibt es - beobachtet nun seit 2 Wochen - keinen einzigen 'transmit miss' oder 'failure' mehr. Wenn ich den Background Scan aktiviere, sind es prompt 4-5 pro Tag, manchmal auch als Burst deutlich mehr.

Nun finde ich das seltsam, denn das würde ja bedeuten, dass die ungepaarte P2P Verbindung im Leerlauf keine Beacons versendet und es aber während eines Background-Scan tut. Dabei ist es aber doch eher umgekehrt, oder?

Die einzige Erklärung, die mir einfällt, wäre die, dass die einzelnen Background-Scans durch das nicht-802.11a-Hintergrundgebrösel so in die Länge gezogen werden, dass der 'Vordergundtask Beacons versenden' aus dem Takt kommt.