OpenWrt DFS/Experiment - Versionsgeschichte

MathiasMahnke: /* Zusammenfassung */

2016-12-23T10:48:03Z

Zusammenfassung

← Nächstältere Version		Version vom 23. Dezember 2016, 10:48 Uhr
Zeile 1:		Zeile 1:
	< [[OpenWrt DFS]]		< [[OpenWrt DFS]]

	== ~~Zusammenfassung~~ ==		== 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.		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.

MathiasMahnke: /* Überblick */

2016-12-23T10:47:44Z

Überblick

← Nächstältere Version		Version vom 23. Dezember 2016, 10:47 Uhr
Zeile 7:		Zeile 7:
	Wir haben versucht die Ursachen zu ermitteln (Wirklich so viele Radareffekte oder eher Fehler in Hard- und Software?) und erste Lösungsvorschläge entwickelt.		Wir haben versucht die Ursachen zu ermitteln (Wirklich so viele Radareffekte oder eher Fehler in Hard- und Software?) und erste Lösungsvorschläge entwickelt.

	== Überblick ==		== 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.		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.

MathiasMahnke: kleine Anpassungen, okay?

2016-12-23T10:47:11Z

kleine Anpassungen, okay?

← Nächstältere Version		Version vom 23. Dezember 2016, 10:47 Uhr
Zeile 1:		Zeile 1:
			< [[OpenWrt DFS]]
	=DFS-Experiment=

	==Zusammenfassung==		== Zusammenfassung ==
⚫	~~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~~.
	Wir nutzen OpenWRT auf 5-GHz-fähigen Access-Points, die "draußen" hängen. Wir haben untersucht, woran das liegen könnten (Wirklich so viel Radar hier? Bugs in der Hard- oder Software?) und Lösungsvorschläge entwickelt.

		⚫	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.
	==Hintergrund==

⚫	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.
			Wir haben versucht die Ursachen zu ermitteln (Wirklich so viele Radareffekte oder eher Fehler in Hard- und Software?) und erste Lösungsvorschläge entwickelt.

			== Ü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.

	===Technischer Hintergrund===
	Im 5 GHz-Band gibt es 19 Kanäle, die in Deutschland genutzt werden dürfen:		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 36–48 nur in Innenräumen erlaubt, DFS nicht nötig
Zeile 20:		Zeile 22:
	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).		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)~~=====~~		'''Frequenzen des Deutschen Wetterradars vom DWD (Stand Nov. 2016)'''

	{\| {{prettytable}}		{\| {{prettytable}}
	! Standort		! Standort
Zeile 80:		Zeile 83:
	\|}		\|}

	==~~Das~~ Problem==		== 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.		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).		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 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.
Zeile 90:		Zeile 93:
	Es ist aus unserer Sicht sehr unwahrscheinlich, dass wir in Rostock auf allen möglichen Kanälen tatsächlich aktive Radarsysteme sehen.		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.		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.		Um das näher zu untersuchen, haben wir ein kleines Experiment durchgeführt.

	==DFS-Experiment==		== DFS Experiment ==

	Wir wollen die Radar-Ereignisse näher untersuchen und dazu im ersten Schritt die Ereignisse loggen und dann analysieren.		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).		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: <pre>echo 0x10400 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug</pre> (das ist leider bei Embedded-Systemen nicht immer eincompiliert)		Wir haben im Treiber DFS-Debugging aktiviert: <pre>echo 0x10400 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug</pre> (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.		Die WLAN-Karte betreiben wir dabei im Monitor-Mode, denn wir wollen auf keinen Fall durch Aussendungen ein Radar-System stören.
Zeile 109:		Zeile 113:
	Dieses Setup haben wir mehrere Tage auf einem AP laufen lassen, der auf einem Dach mit "guten Empfang des Wetterradars" angebracht war.		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.		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).		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.		Wir haben dann zwei verschiedene Anpassungen in der Mustererkennung im DFS-Code von ath9k ausprobiert.
	Außerdem haben wir noch probehalber mal ein [http://www.hydrosoft.net/Enclosure/e5.jpg Abschirm-Blech] (unseres sieht so ähnlich aus) an den hinter den AP gesetzt, das Einstreuungen (von seitlich/hinter dem AP) abschirmen soll.		Außerdem haben wir noch probehalber mal ein [http://www.hydrosoft.net/Enclosure/e5.jpg Abschirm-Blech] (unseres sieht so ähnlich aus) an den hinter den AP gesetzt, das Einstreuungen (von seitlich/hinter dem AP) abschirmen soll.

	===Erstes Ergebnis===		== Erstes Ergebnis ==

	Die Optimierungen im DFS-Code reduzieren die Anzahl der (vermuteten) false-positive Radar-Erkennungen auf den ~~Känalen~~, 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.		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.		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==		== 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.		* 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.		* 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ächser~~ 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.		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)~~==		== Links ==

			(müssten noch einsortiert werden)
	* http://hub.silexamerica.com/unwired/en300-328-v1-9-1		* http://hub.silexamerica.com/unwired/en300-328-v1-9-1
	* https://wiki.opennet-initiative.de/wiki/OpenWrt_DFS		* https://wiki.opennet-initiative.de/wiki/OpenWrt_DFS
	* https://wireless.wiki.kernel.org/en/developers/dfs		* https://wireless.wiki.kernel.org/en/developers/dfs

	==Kontakt==		== 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.		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.

Leo: Kontakt hinzugefügt

2016-12-21T21:52:33Z

Kontakt hinzugefügt

← Nächstältere Version		Version vom 21. Dezember 2016, 21:52 Uhr
Zeile 131:		Zeile 131:
	* https://wiki.opennet-initiative.de/wiki/OpenWrt_DFS		* https://wiki.opennet-initiative.de/wiki/OpenWrt_DFS
	* https://wireless.wiki.kernel.org/en/developers/dfs		* https://wireless.wiki.kernel.org/en/developers/dfs

			==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.

Leo: /* Technischer Hintergrund */ Wetterradar Frequenzen

2016-12-21T21:42:56Z

Technischer Hintergrund: Wetterradar Frequenzen

@@ Zeile 18: / Zeile 18: @@
 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. Nach unserer Kenntnis an folgenden Standorten auf folgenden Frequenzen:
+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).
 ==Das Problem==

Leo: /* Fazit */

2016-12-21T21:30:51Z

Fazit

← Nächstältere Version		Version vom 21. Dezember 2016, 21:30 Uhr
Zeile 61:		Zeile 61:
	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.		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===		==Fazit==

	* 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.		* 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.
Zeile 67:		Zeile 67:

	Unser nächser 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.		Unser nächser 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)==		==Links (müssten noch einsortiert werden)==

Leo: /* DFS-Experiment */

2016-12-21T21:26:55Z

DFS-Experiment

← Nächstältere Version		Version vom 21. Dezember 2016, 21:26 Uhr
Zeile 1:		Zeile 1:
	=DFS-Experiment=		=DFS-Experiment=

	==~~TL;DR~~==		==Zusammenfassung==
	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.		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.
	Wir nutzen OpenWRT auf 5-GHz-fähigen Access-Points, die "draußen" hängen. Wir haben untersucht, woran das liegen könnten (Wirklich so viel Radar hier? Bugs in der Hard- oder Software?) und Lösungsvorschläge entwickelt.		Wir nutzen OpenWRT auf 5-GHz-fähigen Access-Points, die "draußen" hängen. Wir haben untersucht, woran das liegen könnten (Wirklich so viel Radar hier? Bugs in der Hard- oder Software?) und Lösungsvorschläge entwickelt.

Till: erste Fassung

2016-12-21T19:55:47Z

erste Fassung

Neue Seite

=DFS-Experiment=

==TL;DR==
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.
Wir nutzen OpenWRT auf 5-GHz-fähigen Access-Points, die "draußen" hängen. Wir haben untersucht, woran das liegen könnten (Wirklich so viel Radar hier? Bugs in der Hard- oder Software?) und Lösungsvorschläge entwickelt.

==Hintergrund==
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.

===Technischer Hintergrund===
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. Nach unserer Kenntnis an folgenden Standorten auf folgenden Frequenzen:
* [Tabelle einfügen]

==Das 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: <pre>echo 0x10400 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug</pre> (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 [http://www.hydrosoft.net/Enclosure/e5.jpg 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 Känalen, 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===

* 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ächser 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)==
* http://hub.silexamerica.com/unwired/en300-328-v1-9-1
* https://wiki.opennet-initiative.de/wiki/OpenWrt_DFS
* https://wireless.wiki.kernel.org/en/developers/dfs