WLAN Kanalscan

Fourty2 · Beitrag von **Fourty2** » 27 Jun 2005, 23:18

Hallo,

könnte man den WLAN-Kanalscan
http://<Routername>/config/1/3/42/

auch verfügbar machen, wenn ein fester Kanal eingestellt ist?
Das würde bisweilen die Fehlersuche erleichtern, wenn der
Nachbar knapp daneben stört...

Grüße,
Stefan

Casey · Beitrag von **Casey** » 28 Jun 2005, 13:48

Das würde in vielen fällen wenig nützen weil der Kanalscan die einzelnen Kanäle viel zu schnell wechselt um sowohl den Rauschpegel als auch andere APs zuverlässig erkennen zu können.
Die Verweildauer auf einem Kanal sollte deshalb auf längere Zeiten konfigurierbar sein.

Momentan ist es nämlich oft so das andere APs erst bemerkt werden wenn der Kanal schon ausgewählt wurde, dann ist es allerdings schon zu spät.

Oft überlappen sich dann die Kanäle mit anderen APs auf Kanal 11 obwohl die unteren 8 Kanäle in den meisten Fällen frei sind und ähnlich gute tatsächliche Rauschpegel aufweisen.

Bei der Bugliste die sich nach ein paar Minuten Test der 5er Firmware aufgetan hat erscheint das allerdings erstmal vergleichsweise unwichtig.
Mal sehen wieviel davon in der nächsten Firmware von der QS gefunden und behoben werden.

alf29 · Beitrag von **alf29** » 28 Jun 2005, 16:04

Moin,

praktisch alle APs strahlen 10 Beacons pro Sekunde aus, und Probe-Requests/Responses
sind sehr kurze Pakete, die üblicherweise auch noch am Rand der Empfangsreichweite
'durchkommen'. Eine Verweildauer von 1 Sekunde bei passivem und einer halben
Sekunde bei aktivem Scanning war deshalb bisher immer ausreichend, um APs zu finden,
die auch eine relevante 'Belastung' des fraglichen Kanals darstellen. Längere Zeiten
wäre zwar möglich, aber ich glaube nicht, daß man da wesentlich mehr APs findet - und
die Leute sind eigentlich heilfroh, daß sie bei 11a gerade die langen Wartezeiten los
werden....das von Dir beschriebene Szenario habe ich in der Praxis bisher nicht
beobachten können.

Bei der Bugliste die sich nach ein paar Minuten Test der 5er Firmware aufgetan hat erscheint das allerdings erstmal vergleichsweise unwichtig.
Mal sehen wieviel davon in der nächsten Firmware von der QS gefunden und behoben werden.

Die QS-Phase bei der 5.00 war zugegebenermaßen nicht so lang wie bei der 4.12, man
ist da durch das Projektgeschäft nicht immer frei, wann eine Firmware mit einem bestimmten
neuen Feature 'raus muß', und wenn wir sie nicht allgemein freigeben würden, würden
wieder andere Laute meckern, wieso die ihnen vorenthalten wird...

Gruß Alfred

Casey · Beitrag von **Casey** » 28 Jun 2005, 21:08

alf29 hat geschrieben: praktisch alle APs strahlen 10 Beacons pro Sekunde aus, und Probe-Requests/Responses sind sehr kurze Pakete, die üblicherweise auch noch am Rand der Empfangsreichweite 'durchkommen'. Eine Verweildauer von 1 Sekunde bei passivem und einer halben Sekunde bei aktivem Scanning war deshalb bisher immer ausreichend, um APs zu finden,
die auch eine relevante 'Belastung' des fraglichen Kanals darstellen. Längere Zeiten wäre zwar möglich, aber ich glaube nicht, daß man da wesentlich mehr APs findet - und die Leute sind eigentlich heilfroh, daß sie bei 11a gerade die langen Wartezeiten los werden....das von Dir beschriebene Szenario habe ich in der Praxis bisher nicht beobachten können.

Das Problem sind auch nicht die schwach empfangbaren APs sondern die entfernten Clients die an diesen APs hängen und bei Kanalüberlappungen am eigenen AP Störungen produzieren.

APs mit einer SNR von wenigen dB werden so leider nicht zuverlässig gefunden, so dass deren Clients dann je nach gewähltem Kanal deutlich den Rauschpegel anheben und die Übertragungsraten drücken.
Letztens endes ist man so gezwungen auf die Automatik zu verzichten, schade eigentlich.

Die QS-Phase bei der 5.00 war zugegebenermaßen nicht so lang wie bei der 4.12, man ist da durch das Projektgeschäft nicht immer frei, wann eine Firmware mit einem bestimmten neuen Feature 'raus muß', und wenn wir sie nicht allgemein freigeben würden, würden wieder andere Laute meckern, wieso die ihnen vorenthalten wird...

Das wäre auch nicht weiter wild wenn wenigstens Bugfix Firmwares nach der reift beim Kunden Phase zeitnah (bei Bugfix only Releases z.B. ohne zeitraubende QS) verfügbar gemacht würden was bei der 4.14 nicht der Fall gewesen ist (obwohl Bugfix only nicht öffentlich verfügbar).
Stattdessen kommt direkt die 5 mit Fixes für die alten Bugs dafür aber auch mit vielen neuen Bugs. Sodass sowohl Hersteller als auch Kunde von Version zu Version hecheln.
Beim Linuxkernel hat sich ja z.B. durch die x.x.x.x stable Versionen eine deutliche Verbesserung ergeben, bei Microsoft und Lancom dagegen, "ist im nächsten Release das irgendwann kommt behoben".

alf29 · Beitrag von **alf29** » 28 Jun 2005, 21:54

Das wäre auch nicht weiter wild wenn wenisgtens Bugfix Firmwares nach der reift beim Kunden Phase zeitnah (bei Bugfix only Releases z.B. ohne zeitraubende QS) verfügbar gemacht würden was bei der 4.14 nicht der Fall gewesen ist (obwohl Bugfix only nicht öffentlich verfügbar).
Stattdessen kommt direkt die 5 mit Fixes für die alten Bugs dafür aber auch mit vielen neuen Bugs. Sodass sowohl Hersteller als auch Kunde von Version zu Version hecheln.
Beim Linuxkernel hat sich ja z.B. durch die x.x.x stable Versionen eine deutliche Verbesserung ergeben, bei Microsoft und Lancom dagegen, "ist im nächsten Release das irgendwann kommt behoben".

Jede Release, auch wenn sie ein Bugfix-Release ist, muß durch die QS, und dabei
gehen Resourcen verloren, die dann für die nächste 'wichtige' Release, an der die
Projekte hängen, nicht zur Verfügung stehen. Die 4.14 hat's ja gegeben, aber
eben nur auf Anfrage, wenn ein Kunde (bekannte) Probleme hat. Ich bedaure,
aber im mometantne Korsett aus Freigabeterminen und verfügbaren Resourcen
geht's nicht anders. Wenn Dich das stört, neenne ich Dir gerne Ansprechpartner,
die da mehr bewirken können als wir Entwicker...

Gruß Alfred