Ich habe auf verschiedenen Verbindungen immer wieder Leitungsauffälle, und anschließend folgenden Eintrag im Log:
WLAN-1 Channel change due to radar interference
Vor einem Jahr gab es bereits ein ähnliches Thema. Allerdings unter Software-Version 4.12. Dort gab es folgende Einträge im Log:
WLAN-1 Channel change due to radar interference 000b6b30a7c0
Die Ursache war, dass die Accesspoints eigene Signale als Radar-Signale interpretierten.
Meine Fragen sind nun: Mein Log-Eintrag ist leider ohne MAC-Adresse (Version 5.20). Heißt das, dass es sich wirklich um eine echte Radar-Störung handelt? Oder wie kann ich herausfinden, wer hier stört?
Gruß
Panjan
WLAN-1 Channel change due to radar interference
Moderator: Lancom-Systems Moderatoren
Moin,
da kann ich Dir keinen Termin nennen. Unempfindlicher
kann man die Sache nicht stellen, ohne daß das Gerät
durch die Zulassung fällt, und genauer können die
momentanen Chips Radar-Impulse nicht erkennen.
Ist zufällig Kompression auf der Strecke aktiviert?
Seit der 5.0 dauert der Kanalwechsel keine 2 Minuten mehr,
sondern höchstens noch ~20 Sekunden. Wenn da
eine Applikation die Verbindung beendet, dann ist
sie einfach besch*** programmiert.
Gruß Alfred
da kann ich Dir keinen Termin nennen. Unempfindlicher
kann man die Sache nicht stellen, ohne daß das Gerät
durch die Zulassung fällt, und genauer können die
momentanen Chips Radar-Impulse nicht erkennen.
Ist zufällig Kompression auf der Strecke aktiviert?
Seit der 5.0 dauert der Kanalwechsel keine 2 Minuten mehr,
sondern höchstens noch ~20 Sekunden. Wenn da
eine Applikation die Verbindung beendet, dann ist
sie einfach besch*** programmiert.
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Moin,
nein, das hatte in der 4.x auch nichts mit dem auslösenden
Gerät zu tun, das war einfach nur die MAC-Adresse des
eigenen WLAN-Interface. Da Radar-Pulse per definition etwas sind, was sich nicht als WLAN-Paket demodulieren
läßt, kann man daraus auch keine MAC-Adresse entnehmen.
Eine 'auslösende' MAC-Adresse ließe sich bestenfalls
angeben, wenn eine Gegenstelle (Station oder P2P-Slave)
einen Radarpuls erkannt hat und dieses per 11h-Paket
an den AP meldet.
Gruß Alfred
nein, das hatte in der 4.x auch nichts mit dem auslösenden
Gerät zu tun, das war einfach nur die MAC-Adresse des
eigenen WLAN-Interface. Da Radar-Pulse per definition etwas sind, was sich nicht als WLAN-Paket demodulieren
läßt, kann man daraus auch keine MAC-Adresse entnehmen.
Eine 'auslösende' MAC-Adresse ließe sich bestenfalls
angeben, wenn eine Gegenstelle (Station oder P2P-Slave)
einen Radarpuls erkannt hat und dieses per 11h-Paket
an den AP meldet.
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Hallo Alf,
mit Bemerkungen wie "einfach besch*** programmiert." bin ich auf Mailinglisten vorsichtig. Könnte ein Bummerang werden.
Problem: Bei jedem Kanalwechsel aufgrund erkannter Radar-Pulse füllt sich die Blacklist. Ist die Liste voll, geschieht ein "Channel change due to ETSI DFS time limit", und die Verbindung fällt für 60 sec. aus. Und das kann um 10 Uhr Morgens passieren, aber auch um 15 Uhr, sprich: wenn man sich eigentl. keinen Ausfall erlauben kann.
Hier muss sich dringend etwas tun! Hoffentlich sagen wir bald "Implementierung von DFS in 5.20? - besch*** programmiert".
Wenn nicht: Ich arbeite z. Zt. ausschließlich mit P2P-Verbindungen. Dann würde ich darum bitten, das dringend zu implementieren.
Könnte man die Radar-Puls-Erkennung auch an die SSID koppeln?
Gruß
Panjan
mit Bemerkungen wie "einfach besch*** programmiert." bin ich auf Mailinglisten vorsichtig. Könnte ein Bummerang werden.
Problem: Bei jedem Kanalwechsel aufgrund erkannter Radar-Pulse füllt sich die Blacklist. Ist die Liste voll, geschieht ein "Channel change due to ETSI DFS time limit", und die Verbindung fällt für 60 sec. aus. Und das kann um 10 Uhr Morgens passieren, aber auch um 15 Uhr, sprich: wenn man sich eigentl. keinen Ausfall erlauben kann.
Hier muss sich dringend etwas tun! Hoffentlich sagen wir bald "Implementierung von DFS in 5.20? - besch*** programmiert".
Ist das bereits implementiert? Dann wüsste ich gerne, wie.Eine 'auslösende' MAC-Adresse ließe sich bestenfalls
angeben, wenn eine Gegenstelle (Station oder P2P-Slave)
einen Radarpuls erkannt hat und dieses per 11h-Paket
an den AP meldet.
Wenn nicht: Ich arbeite z. Zt. ausschließlich mit P2P-Verbindungen. Dann würde ich darum bitten, das dringend zu implementieren.
Könnte man die Radar-Puls-Erkennung auch an die SSID koppeln?
Gruß
Panjan
Moin,
die ETSI-Vorschriften auf der einen Seite und die
Fähigkeiten der Hardware auf der anderen Seite die Hände
gebunden...man kann die Mustererkennung etwas
empfindlicher einstellen, was das Risiko von Fehl-
erkennungen reduziert, aber dann läuft man wieder das
Risiko, daß die RegTP bei der nächsten Überprüfung
uns eins auf den Deckel gibt, weil DFS mit ihren
Testmustern nicht tut.
ein P2P-Slave mit mehr als 200mW EIRP im ETSI-Dokument
als 'High-Power-Client' gilt und so etwas können muß.
Die Übermittlung vom Slave an den Master erfolgt durch
ein 11h-Paket (Autonomous Basic Measurement Report)
und würde im WLAN-Log als solche vermerkt werden - mit
der MAC-Adresse, von wo das kam. Der weitere Ablauf
mit Markieren und Kanalwechsel ist identisch, als wenn
der Master selber das Radarmuster erkannt hätte.
auf der gleichen Hardware und die kann nur auf einem
Kanal arbeiten - unterschiedliche logische Netze können
deshalb nicht auf unterschiedlichen Kanälen laufen.
Gruß Alfred
Wir würden daran gerne etwas tun, uns sind aber durchHier muss sich dringend etwas tun! Hoffentlich sagen wir bald "Implementierung von DFS in 5.20? - besch*** programmiert".
die ETSI-Vorschriften auf der einen Seite und die
Fähigkeiten der Hardware auf der anderen Seite die Hände
gebunden...man kann die Mustererkennung etwas
empfindlicher einstellen, was das Risiko von Fehl-
erkennungen reduziert, aber dann läuft man wieder das
Risiko, daß die RegTP bei der nächsten Überprüfung
uns eins auf den Deckel gibt, weil DFS mit ihren
Testmustern nicht tut.
Das ist seit der 5.0x implementiert - u.a. deswegen, weilIst das bereits implementiert? Dann wüsste ich gerne, wie.
Wenn nicht: Ich arbeite z. Zt. ausschließlich mit P2P-Verbindungen. Dann würde ich darum bitten, das dringend zu implementieren.
ein P2P-Slave mit mehr als 200mW EIRP im ETSI-Dokument
als 'High-Power-Client' gilt und so etwas können muß.
Die Übermittlung vom Slave an den Master erfolgt durch
ein 11h-Paket (Autonomous Basic Measurement Report)
und würde im WLAN-Log als solche vermerkt werden - mit
der MAC-Adresse, von wo das kam. Der weitere Ablauf
mit Markieren und Kanalwechsel ist identisch, als wenn
der Master selber das Radarmuster erkannt hätte.
Was darf ich mir darunter vorstellen? Alle SSIDs laufenKönnte man die Radar-Puls-Erkennung auch an die SSID koppeln?
auf der gleichen Hardware und die kann nur auf einem
Kanal arbeiten - unterschiedliche logische Netze können
deshalb nicht auf unterschiedlichen Kanälen laufen.
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Hallo,
am 06.02.06 schriebst du:
Wenn ich eine P2P-Verbindung habe, kann es vorkommen, dass die Access-Points Signale des Access-Points der Gegenstelle als Radar-Signale interpretieren. Oder sind es sogar die ausgesandten Signale, also die eigenen?
Deshalb kam mein Vorschlag: Nicht nur die Frequenz, sondern auch die SSID überprüfen, weil dann doch klar ist, wo das Signal herkommt (und eben kein Radar-Signal ist).
Am 7.2.06 schriebst du dann:
Wäre nett, wenn du mir das näher erläutern würdest. Viell. habe ich ja nur ein Knoten im Denken.
Gruß
Panjan
am 06.02.06 schriebst du:
Daraus habe ich entnommen:das Problem ist immer noch das gleiche.
Wenn ich eine P2P-Verbindung habe, kann es vorkommen, dass die Access-Points Signale des Access-Points der Gegenstelle als Radar-Signale interpretieren. Oder sind es sogar die ausgesandten Signale, also die eigenen?
Deshalb kam mein Vorschlag: Nicht nur die Frequenz, sondern auch die SSID überprüfen, weil dann doch klar ist, wo das Signal herkommt (und eben kein Radar-Signal ist).
Am 7.2.06 schriebst du dann:
mit der Ergänzung am 10.02.06:Eine 'auslösende' MAC-Adresse ließe sich bestenfalls
angeben, wenn eine Gegenstelle (Station oder P2P-Slave)
einen Radarpuls erkannt hat und dieses per 11h-Paket
an den AP meldet.
Danach würde ich sagen: Störungen können nicht von den Access-Points der eigenen WLAN-Strecke erzeugt werden sondern nur von Access-Points anderer P2P-Strecken.Das ist seit der 5.0x implementiert
Wäre nett, wenn du mir das näher erläutern würdest. Viell. habe ich ja nur ein Knoten im Denken.
Gruß
Panjan
Moin,
bei einem Radar-Puls gibt die Atheros-Hardware nur genau
diese Information - daß es ein Radar-Puls ist, man erhält
keine weiteren Informationen außer Signalstärke und
Pulslänge. Ein Radarpuls ist per Definition nichts OFDM-
moduliertes, also nichts, wo einem der Chip etwas wie
eine Quelladresse geben könnte. Ob es ein echtes
Radar ist, ein kaputt gegangenes Paket von der Gegenstelle
oder eine Reflexion des eigenen Signals - man weiß
es nicht...sobald sich aus den Einzelpulsen ein
vorgegebenes Muster ergibt, muß Radar gemeldet werden.
Was ich mit 11h meinte, ist daß diese Mustererkennung
sowohl auf Master als auch Slave läuft. Wenn ein Slave ein
Radarmuster erkennt, dann meldet er das über einen
'normalen' Management-Frame an den Master, der dann
die gleichen Aktionen (Kanalwechsel) anstößt, als ob
sein eigenes Radar-Erkennungsmodul etwas gefunden
hätte.
Gruß Alfred
bei einem Radar-Puls gibt die Atheros-Hardware nur genau
diese Information - daß es ein Radar-Puls ist, man erhält
keine weiteren Informationen außer Signalstärke und
Pulslänge. Ein Radarpuls ist per Definition nichts OFDM-
moduliertes, also nichts, wo einem der Chip etwas wie
eine Quelladresse geben könnte. Ob es ein echtes
Radar ist, ein kaputt gegangenes Paket von der Gegenstelle
oder eine Reflexion des eigenen Signals - man weiß
es nicht...sobald sich aus den Einzelpulsen ein
vorgegebenes Muster ergibt, muß Radar gemeldet werden.
Was ich mit 11h meinte, ist daß diese Mustererkennung
sowohl auf Master als auch Slave läuft. Wenn ein Slave ein
Radarmuster erkennt, dann meldet er das über einen
'normalen' Management-Frame an den Master, der dann
die gleichen Aktionen (Kanalwechsel) anstößt, als ob
sein eigenes Radar-Erkennungsmodul etwas gefunden
hätte.
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015