DFS-Trace - Bug im LCOS 6.12?

[NLange]

Ich habe heute einen L-54ag von 6.04 auf 6.12.0017 geupdated. Das Gerät läuft als 5-GHz-Client in einer Richtstrecke.

Wenn ich dann im Telnet den trace # dfs laufen lasse, so fällt auf, daß er die Kanäle 100, 104, 108 normal scannt. Dann rauscht er im Eiltempo zu Kanal 120 und macht dann mit 120, 124, 128, 132, 136 und 140 normal weiter. Wenn der AP zufällig gerade Kanal 112 oder 116 benutzt, dann findet der Client den AP einfach nicht.

Ich habe dann per Firmsafe gedowngradet auf 6.04 zurück und das Problem war aus der Welt.

In Konfig>Interfaces>WLAN>Phys. Radio war in der Kanalliste nichts eingetragen. Als Land war Deutschland eingestellt. Allgemein scheint die 6.12er Probleme zu haben, den AP zu finden. Selbst wenn der grad nicht 112 oder 116 benutzt.

[alf29]

Moin,

Clients ab LCOS 6.1x benutzen ein gemischt aktiv/passives Scan-Verfahren bei 5 GHz - sobald
der Client auf dem Kanal Beacons empfängt, wechselt er auf aktives Scanning, d.h. er schickt
einen Probe Request und wartet dann noch etwa 20 Millisekunden auf eine Antwort - ein AP,
der nicht innerhalb von 20 Millisekunden antwortet, ist ziemlich überlastet...

Gruß Alfred

[NLange]

Also nun noch mal für kleine Nicht-Lancom-Programmierer

Der AP kann WLAN-seitig nicht überlastet sein denn er hat nur die eine Gegenstelle. Allerdings ist er laut dfs-Trace öfters mal mit Radar beschäftigt. Er erkennt Peaks, wechselt aber den Kanal nicht (Schwellwerte auf Standard).

Derzeit im Probebetrieb habe ich den AP über DynDNS am Inet sodaß ich ihn fernwarten kann. Ich schaue dann nach auf welchem Kanal der ist und den gebe ich beim Client über die Kanalliste vor. Der Link wird sofort aufgebaut. Dabei ist völlig wurscht, welche Kanalnummer der AP grad verwendet. Dieses Procedere klappt bei allen Kanälen.

Lasse ich beim Client die Kanalliste leer so scannt er alle Kanäle im Subband 2 durch aber den AP findet er nicht bzw. nach einigen Stunden Scannerei hat er ihn dann irgendwann.

Nun möcht ich aber auch nicht Tag und Nacht den menschlichen Kanalwechsler machen Kann man irgendwelche Parameter ändern sodaß der AP leichter gefunden wird? Wenn dadurch der DFS-Rescan ein paar Sekunden länger dauert soll mir auch recht sein. Hauptsache die reden wieder vollautomatisch miteinander.

[alf29]

Lasse ich beim Client die Kanalliste leer so scannt er alle Kanäle im Subband 2 durch aber den AP findet er nicht bzw. nach einigen Stunden Scannerei hat er ihn dann irgendwann.

Sieht man auf dem AP Probe Requests vom Client?

Kann man irgendwelche Parameter ändern sodaß der AP leichter gefunden wird?

Nein, diese Timing-Parameter sind hart kodiert. Ich hatte vorher einige Paper zu diesem
Thema gelesen (die schlugen sogar eher 10 ms vor...) und wenn mal all so etwas
konfigurierbar macht, rasten irgendwann die 'normalen' Anwender aus...

enn dadurch der DFS-Rescan ein paar Sekunden länger dauert soll mir auch recht sein.

Mit dem DFS-Rescan hat das nichts zu tun, der passiert ja nur auf dem AP. Und ob der
Scan auf dem Client etwas mehr oder weniger lange dauert, ist inzwischen alles andere
egal, weil alle von Fast Roaming reden (auch bei 5 GHz, vor allem in industriellen
Bereich). Dort wird inzwischen darum gefeilscht, wie tief man mit der Roaming-Zeit in den
Millisekundenbereich herunterkommt.

Es ist mir aber ehrlich gesagt schleierhaft, wieso es einen Unterschied macht, wenn man
den Kanalbereich einschränkt - das neue Scanverfahren gilt immer, egal ob man nur auf
einem oder elf Kanälen sucht...

Gruß Alfred

[NLange]

Sieht man auf dem AP Probe Requests vom Client?

Wie macht man die sichtbar?

Nein, diese Timing-Parameter sind hart kodiert. Ich hatte vorher einige Paper zu diesem Thema gelesen (die schlugen sogar eher 10 ms vor...) und wenn mal all so etwas konfigurierbar macht, rasten irgendwann die 'normalen' Anwender aus...

Ok kann ich nachvollziehen. Das LCOS ist so schon kaum noch überschaubar. Andererseits braucht einer von tausend Anwendern mal ein Feature was nicht da ist wird auch wieder gemeckert. Als Firmware-Programmierer hat mans sicher nicht leicht

Und ob der Scan auf dem Client etwas mehr oder weniger lange dauert, ist inzwischen alles andere egal, weil alle von Fast Roaming reden (auch bei 5 GHz, vor allem in industriellen Bereich). Dort wird inzwischen darum gefeilscht, wie tief man mit der Roaming-Zeit in den Millisekundenbereich herunterkommt.

Na sicher doch. Fast Roaming. Die Richtstrecken-Clients düsen ja auch mit 200 km/h in der Landschaft rum

Nun stellt sich aber die Frage, wie man in schwierigen Fällen (z.B. ungünstiges Gelände, Bebauung usw.) bei zu langer Antwortzeit des AP die Sache in den Griff kriegt. Vielleicht wäre es ne Möglichkeit, den Timing-Parameter-Wust (sind sicher mehr als ein Parameter) an ein einfaches Kriterium zu koppeln. Zum Beispiel eine Combobox wo man die Betriebsart auswählt (Richtfunk/Multiple stationäre Clients/Multiple mobile Clients). Dann gibts halt diese drei Parametersets.

Es ist mir aber ehrlich gesagt schleierhaft, wieso es einen Unterschied macht, wenn man den Kanalbereich einschränkt - das neue Scanverfahren gilt immer, egal ob man nur auf einem oder elf Kanälen sucht...

Warum das so ist weiß ich leider auch nicht. Aber dieses Verhalten ist 100%ig reproduzierbar. Sobald der Kanal am Client fix ist steht der Link innerhalb einer Sekunde.

Ich hätte noch einen kleinen Feature-Request oder Change-Request für das LCOS: Wäre es möglich, die Schriftgröße im Webinterface etwas zu reduzieren oder einstellbar zu machen? Verdana 12px wäre sehr praktisch. Dann klappts auch besser mit diversen Tabellen und hat nicht mehr so viele Zeilenumbrüche.