OpenWrt DFS/Experiment

Aus Opennet
Wechseln zu: Navigation, Suche

< OpenWrt DFS

Inhaltsverzeichnis

Ausgangssituation

In unserer Opennet Infrastruktur haben große Probleme die "Outdoor-Kanäle" im 5-GHz-Band zu nutzen, da die Radar-Erkennung (DFS) häufig Kanalwechsel erfordert. Wir nutzen OpenWrt auf den 5 GHz im Außenbereich installierten Backbone und Nutzer WLAN Access-Points.

Wir haben versucht die Ursachen zu ermitteln (Wirklich so viele Radareffekte oder eher Fehler in Hard- und Software?) und erste Lösungsvorschläge entwickelt.

Technischer Überblick

Motiviert durch die häufigen Radar-Ereignisse haben wir uns näher mit DFS, der Implementierung in Linux (speziell OpenWrt, noch spezieller: der ath9k-Treiber) beschäftigt.

Im 5 GHz-Band gibt es 19 Kanäle, die in Deutschland genutzt werden dürfen:

  • Kanal 36–48 nur in Innenräumen erlaubt, DFS nicht nötig
  • Kanal 52–64 nur in Innenräumen erlaubt, DFS zwingend vorgeschrieben
  • Kanal 100–140 auch außerhalb geschlossener Räume erlaubt, DFS zwingend vorgeschrieben

WLAN-APs, die auf den 5-GHz-Kanälen 52-140 betrieben werden, müssen DFS benutzen, d.h. sie müssen vorgegebene Radarmuster erkennen, im Falle einer Erkennung den Kanal sofort wechseln und den Kanal, auf dem Radar erkannt wurde, für 60 Minuten meiden ("Blacklist").

In ath9k funktioniert die Radarerkennung grob so: Die Hardware meldet einzelne Radarimpulse, der Treiber führt darauf eine Mustererkennung durch und schaut, ob die Pulse zu einem der definierten Radar-Muster (je nach Land werden die Muster von der ETSI, der FCC oder "Japan") passen. Wenn ja, meldet der Treiber dies an eine Schicht weiter nach oben (mac80211). Final landet die Information dann bei hostapd, der entsprechende Maßnahmen ergreift (Kanal wechseln).

Beispiel für ein Radarsystem in Deutschland ist das Wetterradar des DWD im 5-GHz-Band. Aus der nachstehenden Tabelle kann man die Standorte und zugehörigen Frequenzen des Wetterradars entnehmen (nach unserem Kenntnis).

Frequenzen des Deutschen Wetterradars vom DWD (Stand Nov. 2016)

Standort Zugelassene Frequenz
Boostedt 5625 MHz +/-10 MHz
Emden 5640 MHz +/-10 MHz
Hannover 5640 MHz +/-10 MHz
Rostock 5640 MHz +/-10 MHz
Ummendorf 5640 MHz +/-10 MHz
Essen 5640 MHz +/-10 MHz
Flechtdorf 5640 MHz +/-10 MHz
Prötzel 5640 MHz +/-10 MHz
Offenthal 5640 MHz +/-10 MHz
Neuheilenbach 5625 MHz +/-10 MHz
Neuhaus 5625 MHz +/-10 MHz
Dresden 5640 MHz +/-10 MHz
Memmingen 5630 MHz +/-10 MHz
Feldberg 5670 MHz +/-10 MHz
Eisberg 5640 MHz +/-10 MHz
Isen 5625 MHz +/-10 MHz
Türkheim 5600 MHz +/-10 MHz
Hohenpeißenberg 5640 MHz +/-10 MHz

Problem

Wir bei Opennet haben starke Probleme, die "Outdoor-Kanäle" im 5-GHz-Band zu nutzen, weil die Radar-Erkennung (DFS) häufig Kanalwechsel erzwingt.

Unsere Outdoor-APs (u.a. Ubiquiti Nanostation M5, TP-Link CPE 510 ) melden sowohl mit OpenWrt als auch mit AirOS (bei Nanostation) sehr oft Radar und sperren dann den jeweiligen Kanal. Die Meldungen kommen querbeet auf allen Kanälen, auf denen DFS vorgeschrieben ist (52–140).

Wenn man einen AP outdoor betreibt und diesem standardkonform die Nutzung "Indoor-Kanäle" 36–64 verbietet, bleibt manchmal kein Kanal ohne Radar-Sperrung mehr übrig und der AP "schaltet ab" bis zum Ablauf der Sperrzeit. Wenn man dem AP die Auswahl der Kanäle nicht einschränkt, landet er früher oder später auf einem der vier Kanäle, auf denen kein DFS vorgeschrieben ist (36–48) und bleibt auch dort, weil er nie wieder DFS-Meldungen bekommt und daher keinen Grund hat, den Kanal von sich aus jemals wieder zu ändern. Da diese vier Kanäle nicht für die Nutzung außerhalb geschlossener Räume vorgesehen sind, ist das ein eher unbefriedigender Zustand. Es ist aus unserer Sicht sehr unwahrscheinlich, dass wir in Rostock auf allen möglichen Kanälen tatsächlich aktive Radarsysteme sehen. Wir vermuten, dass die Radarerkennung entweder überempfindlich ist, und/oder dass etwas anderes (z.B. WLAN-Traffic von benachbarten APs) zu Fehl-Erkennungen führt.

Um das näher zu untersuchen, haben wir ein kleines Experiment durchgeführt.

DFS Experiment

Wir wollen die Radar-Ereignisse näher untersuchen und dazu im ersten Schritt die Ereignisse loggen und dann analysieren. Dafür haben wir einen OpenWrt-AP mit einer WLAN-NIC, die von ath9k unterstützt wird, verwendet (Ubiquiti Nanostation M5).

Wir haben im Treiber DFS-Debugging aktiviert:
echo 0x10400 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug
(das ist leider bei Embedded-Systemen nicht immer eincompiliert)

Die WLAN-Karte betreiben wir dabei im Monitor-Mode, denn wir wollen auf keinen Fall durch Aussendungen ein Radar-System stören.

Erkenntnis: Die Radarerkennung wird vom Treiber nur aktiviert, wenn mac80211 das fordert. mac80211 fordert das nur, wenn ein Interface im AP-Modus ist, und auf dem konfigurierten Kanal DFS vorgeschrieben ist. Also haben wir erstmal im Monitor-Mode kein DFS. :-(

Unsere Lösung: Wir patchen ath9k so, dass die Radarerkennung immer aktiv ist (als Nebeneffekt auch auf den Kanälen 36–48). Im Syslog landen dann je nach eingestelltem Kanal jede Menge Meldungen über Radar, und zwar

  • Meldungen über einzelne Radar-Impulse
  • Meldungen über erkannte Radar-Muster

Dieses Setup haben wir mehrere Tage auf einem AP laufen lassen, der auf einem Dach mit "guten Empfang des Wetterradars" angebracht war. Aufgrund der vielen Logmeldungen haben wie diese per remote-syslog auf ein anderes System gesendet und dort gespeichert. Am Ende hatten wir 5,1 GiB Syslog Dateien mit 30,6 Mio. Radar-Impulsen und 1,2 Mio. Radar-Ereignissen (=erkannten Radar-Mustern).

Wir haben dann zwei verschiedene Anpassungen in der Mustererkennung im DFS-Code von ath9k ausprobiert. Außerdem haben wir noch probehalber mal ein Abschirm-Blech (unseres sieht so ähnlich aus) an den hinter den AP gesetzt, das Einstreuungen (von seitlich/hinter dem AP) abschirmen soll.

Erstes Ergebnis

Die Optimierungen im DFS-Code reduzieren die Anzahl der (vermuteten) false-positive Radar-Erkennungen auf den Kanälen, auf denen nach unserer Kenntnis *kein* Radar ist, dramatisch (auf nahe Null). Auf den Kanälen, auf denen nach unserer Kenntnis ein Radar-System empfangbar ist (=true positive), sehen wir nach Anwendung der Optimierungen weiterhin sehr viele Radar-Ereignisse. Das heißt, die Radarerkennung wurde durch die Optimierung augenscheinlich nicht geschwächt.

Außerdem zeigte sich, dass das Abringen des Bleches die Anzahl der erkannten Radar-Impulse um etwa ein Drittel senkt. Die Auswirkungen auf die erkannten Radar-Muster sind aber leider nicht so eindeutig.

Fazit und Ausblick

  • Die Radarerkennung im ath9k-Code scheint sehr anfällig für False-Positives zu sein, d.h. sie reagiert überempfindlich und meldet Radar häufig auch dann, wenn gar kein Radar da ist.
  • Optimierungen im Code der Radarerkennung können diese Fehlerkennungen deutlich verringern und dadurch die Outdoor-Kanäle nutzbarer machen, ohne jedoch die Erkennung von tatsächlichem Radar zu schwächen.

Unser nächster Schritt: Wir wollen den DFS-Pattern-Detection-Code aus ath9k herrauslösen und "stand alone"-lauffähig machen (als C-Programm). Dieses Programm können wir dann mit unseren aufgezeichneten Pulsfolgen aus dem Experiment "füttern" und verschiedene Optimierungen ausprobieren, ohne ein Test-Setup zu benötigen.

Links

(müssten noch einsortiert werden)

Kontakt

Wenn ihr euch für das Thema interessiert und darüber reden/schreiben/kommunizieren wollt, dann schreibt einfach eine Mail an dev<ät>opennet-initiative<punkt>de.

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge