Hallo,
ich habe für zwei Basisstationen (L-54ag und OAP-54), die im Band 2 im 54MBit-Normal-Modus konfiguriert sind (Software-Version 5.20) versucht, in den Turbo-Modus umzuschalten. Ich habe erst das ferne Gerät geändert, dann mein lokales Gerät. Das war's dann. Keine Verbindung mehr.
Kanalnummer steht auf "Automatische Auswahl", Kanal-Liste ist nicht konfiguriert.
Ich vermute jetzt, dass kein freier Turbo-Kanal gefunden wird. (Wo kann ich nachsehen, ob meine Vermutung richtig ist?)
Wenn dem so ist: Von unserem Gebäude gehen 7 WLAN-Strecken ab. Kann es sein, dass Turbo hier gar nicht geht, weil die Strecken sich dann gegenseitig stören?
Gruß
Panjan
2 Basisstationen im Band 2 im Turob-Modus verbinden
Moderator: Lancom-Systems Moderatoren
Moin,
soll - wenn alle Kanäle belegt sind, spricht nichts dagegen,
daß mit dem n+1-ten AP Kanäle doppelt belegt werden.
Auf dem Master sollte man mit dem DFS-Trace erstmal
prüfen, ob er einen Kanal auswählt, auf dem er dann
in Betrieb geht. Dann kann man auf dem Slave schauen,
was der macht.
Gruß Alfred
Das spielt bei aktiviertem DFS ohnehin keine Rolle.Kanalnummer steht auf "Automatische Auswahl", Kanal-Liste ist nicht konfiguriert.
DFS heißt nur, daß das Band gleichmäßig genutzt werdenIch vermute jetzt, dass kein freier Turbo-Kanal gefunden wird. (Wo kann ich nachsehen, ob meine Vermutung richtig ist?)
Wenn dem so ist: Von unserem Gebäude gehen 7 WLAN-Strecken ab. Kann es sein, dass Turbo hier gar nicht geht, weil die Strecken sich dann gegenseitig stören?
soll - wenn alle Kanäle belegt sind, spricht nichts dagegen,
daß mit dem n+1-ten AP Kanäle doppelt belegt werden.
Auf dem Master sollte man mit dem DFS-Trace erstmal
prüfen, ob er einen Kanal auswählt, auf dem er dann
in Betrieb geht. Dann kann man auf dem Slave schauen,
was der macht.
Gruß Alfred
Hallo Alf,
ich liefere keine Trace-Daten, sondern meinen Versuchsaufbau. Viell. kannst du damit ja den Fehler reproduzieren.
Mein (vorläufiges Fazit): Man muss bei der Umstellung auf den Turbo-Modus als erstes die Master-Basisstation umstellen.
Mein Test:
Eine Strecke mit 3 OAPs (der OAP2 ist Repeater):
1. Strecke:
OAP1, WLAN2, Master
OAP2, WLAN1, Slave
2. Strecke:
OAP2, WLAN2, Master
OAP3, WLAN2, Slave
Zunächst habe ich OAP3, WLAN2 auf Turbo umgestellt, dann OAP2, WLAN2. Beide Geräte haben sich auf Kanal 130 gefunden.
Dann habe ich OAP2, WLAN1 umgestellt. Er hat sich auf Kanal 106 eingependelt. Da der OAP1, WLAN2 Kanal 130 eine Verbindung aufbauen will, kommen die beiden nicht zusammen. Zunächst dachte ich: Der OAP2 hat Probleme, auf beiden Ports den gleichen Kanal zu benutzen
Daraufhin habe die Umstellung auf der Strecke OAP1 - OAP2 rückgängig gemacht und erst OAP1, WLAN2 umgestellt (Master) und dann den OAP2, WLAN1 (Slave). Jetzt haben sie sich auf Kanal 130 getroffen.
Das gleiche habe ich noch einmal wiederholt. Der Effekt hat sich bestätigt. Wieder habe ich zuerst den OAP2, WLAN1 umstellt und sofort nach dem Speichern den OAP1, WLAN2. Der OAP2, WLAN1 ging auf Kanal 122, der OAP1, WLAN2 auf Kanal 130 und damit war der Fehler wieder da.
Nun habe ich den OAP2 über Kaltstart neu gestartet und fand eine Verbindung zum OAP1 über Kanal 130. Der OAP3 hat gemerkt, dass durch den Neustart seine Verbindung zum OAP2 verloren gegangen ist, hat seine Kanäle neu gesucht und jetzt haben sie eine funktionierende Verbindung über Kanal 114.
Die Reihenfolge: Erst Master, dann Slave hat allerdings einen großen Nachteil: Ich habe meine P2P-Strecken so konfiguriert, dass, vom Administrations- und Syslog-Server aus gesehen, immer zuerst der Master kommt, dann der Slave, da die Syslog-Meldungen des Masters viel aussagekräftiger sind. Wenn ich also zuerst den Master umstelle muss, hat das zur Folge, dass ich für die Umstellung des Slave erst einmal in die Außenstelle fahren muss. Ich kann bei einem Firmewareupdate auch nicht mehr erst den fernen OAP und dann den lokalen OAP updaten.
Wenn du trotz allem noch einen Trace benötigst, werde ich ihn baldmöglichst nachliefern.
Soweit zu diesem Problem
Panjan
ich liefere keine Trace-Daten, sondern meinen Versuchsaufbau. Viell. kannst du damit ja den Fehler reproduzieren.
Mein (vorläufiges Fazit): Man muss bei der Umstellung auf den Turbo-Modus als erstes die Master-Basisstation umstellen.
Mein Test:
Eine Strecke mit 3 OAPs (der OAP2 ist Repeater):
1. Strecke:
OAP1, WLAN2, Master
OAP2, WLAN1, Slave
2. Strecke:
OAP2, WLAN2, Master
OAP3, WLAN2, Slave
Zunächst habe ich OAP3, WLAN2 auf Turbo umgestellt, dann OAP2, WLAN2. Beide Geräte haben sich auf Kanal 130 gefunden.
Dann habe ich OAP2, WLAN1 umgestellt. Er hat sich auf Kanal 106 eingependelt. Da der OAP1, WLAN2 Kanal 130 eine Verbindung aufbauen will, kommen die beiden nicht zusammen. Zunächst dachte ich: Der OAP2 hat Probleme, auf beiden Ports den gleichen Kanal zu benutzen
Daraufhin habe die Umstellung auf der Strecke OAP1 - OAP2 rückgängig gemacht und erst OAP1, WLAN2 umgestellt (Master) und dann den OAP2, WLAN1 (Slave). Jetzt haben sie sich auf Kanal 130 getroffen.
Das gleiche habe ich noch einmal wiederholt. Der Effekt hat sich bestätigt. Wieder habe ich zuerst den OAP2, WLAN1 umstellt und sofort nach dem Speichern den OAP1, WLAN2. Der OAP2, WLAN1 ging auf Kanal 122, der OAP1, WLAN2 auf Kanal 130 und damit war der Fehler wieder da.
Nun habe ich den OAP2 über Kaltstart neu gestartet und fand eine Verbindung zum OAP1 über Kanal 130. Der OAP3 hat gemerkt, dass durch den Neustart seine Verbindung zum OAP2 verloren gegangen ist, hat seine Kanäle neu gesucht und jetzt haben sie eine funktionierende Verbindung über Kanal 114.
Die Reihenfolge: Erst Master, dann Slave hat allerdings einen großen Nachteil: Ich habe meine P2P-Strecken so konfiguriert, dass, vom Administrations- und Syslog-Server aus gesehen, immer zuerst der Master kommt, dann der Slave, da die Syslog-Meldungen des Masters viel aussagekräftiger sind. Wenn ich also zuerst den Master umstelle muss, hat das zur Folge, dass ich für die Umstellung des Slave erst einmal in die Außenstelle fahren muss. Ich kann bei einem Firmewareupdate auch nicht mehr erst den fernen OAP und dann den lokalen OAP updaten.
Wenn du trotz allem noch einen Trace benötigst, werde ich ihn baldmöglichst nachliefern.
Soweit zu diesem Problem
Panjan
Moin,
bis er seinen Master gefunden hat.
Wenn man den Master zuerst umstellt, dann wechselt er auf den neuen (Turbo-)Kanal,
und für den Slave sind die Beacons vom Master auf dem alten (nicht-Turbo) weg und
er fällt in den Scan-Modus zurück. Wenn kein Turbo konfiguriert ist, werden die
Turbo-Kanäle gar nicht gescannt und der Slave wird den Master erst wiederfinden und
mit dem Scan aufhören, wenn er selber auch auf Turbo umgestellt ist - soweit, so gut.
Wenn man aber zuerst den Slave auf Turbo umstellt, dann werden ja auch die nicht-
Turbo-Kanäle mit gescannt (das wird für DFS auf dem Master gebraucht), dann kann
es passieren, daß der Slave den Master noch auf dem nicht-Turbo-Kanal findet, weil
der noch nicht umgestellt ist. Das muß ich mal nachstellen, was dann passiert...
Gruß Alfred
Das sollte er eigentlich gar nicht, denn ein Slave soll ja so lange das Band durchsuchen,Dann habe ich OAP2, WLAN1 umgestellt. Er hat sich auf Kanal 106 eingependelt.
bis er seinen Master gefunden hat.
Wenn man den Master zuerst umstellt, dann wechselt er auf den neuen (Turbo-)Kanal,
und für den Slave sind die Beacons vom Master auf dem alten (nicht-Turbo) weg und
er fällt in den Scan-Modus zurück. Wenn kein Turbo konfiguriert ist, werden die
Turbo-Kanäle gar nicht gescannt und der Slave wird den Master erst wiederfinden und
mit dem Scan aufhören, wenn er selber auch auf Turbo umgestellt ist - soweit, so gut.
Wenn man aber zuerst den Slave auf Turbo umstellt, dann werden ja auch die nicht-
Turbo-Kanäle mit gescannt (das wird für DFS auf dem Master gebraucht), dann kann
es passieren, daß der Slave den Master noch auf dem nicht-Turbo-Kanal findet, weil
der noch nicht umgestellt ist. Das muß ich mal nachstellen, was dann passiert...
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015