OpenWrt DFS: Unterschied zwischen den Versionen

Aus Opennet
Wechseln zu: Navigation, Suche
(Debug-Hinweise)
 
(33 dazwischenliegende Versionen von 8 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
===Enable DFS for OpenWRT===
+
{{team
Aim is to enable DFS for 5GHz wifi band. Until today we found no usable solution to integrade DFS suipport into OpenWRT. Without DFS there is no official 802.11n outdoor channels support.
+
|description=Optimierung der Radarerkennung
 +
|members=[[Benutzer:Till|Till W.]], Kai-Uwe, Björn, [[Benutzer:Leo|Martin G.]] (?)
 +
|kontakt=[https://list.opennet-initiative.de/mailman/listinfo/crew Crew Mailingliste]
 +
|logo=Doppler-Radar-Tower.jpg
 +
}}
  
In the following we will log our approach to (try to) enable DFS.
+
== Problem ==
 +
In OpenWrt ''Chaos Calmer'' ist es möglich, Outdoor-Kanäle auszuwählen. Beim Auftreten von DFS-relevanten Signalmustern findet ein Wechsel auf einen Indoor-Kanal statt. Ein Wechsel zurück auf einen Outdoor-Kanal findet aktuell nicht automatisch statt. DieAnzahl der DFS-Events ist zumindest bei uns, außergewöhnlich hoch, obwohl es hierfür keine offensichtliche Quelle gibt.
  
'''Compile trunk of OpenWRT'''
+
Beim montäglichen Vereinstreffen in der [[Frieda23]] findet sich regelmäßig auch eine Kleingruppe für die Arbeit an der Verbesserung der DFS-Implementierung zusammen.
  
On 2014-01-24 we made SVN checkout of OpenWRT trunk with rev. 39385. All compiled well.
+
== Untersuchungen ==
 +
* [[OpenWrt DFS/Ereignisstatistik]]: Statistik aufgefangener DFS-Signale
 +
* [[OpenWrt DFS/Experiment]]: Experiment und Auswertung der häufigen Radar-Events
  
'''1st Run'''
+
== Notizen ==
 +
=== Aktivierung von Outdoor-Kanälen (2014, ieee80211h=1) ===
 +
In OpenWrt ''Barrier Breaker'' war es nicht möglich, Outdoor-Kanäle zu aktivieren.
  
Thu Jan  1 00:08:10 1970 daemon.notice netifd: radio0 (933): Configuration file: /var/run/hostapd-phy0.conf
+
Die Ursache war der fehlende Eintrag ''ieee80211h=1'' in der ''hostapd.conf''. Das von uns eingereichte [https://dev.openwrt.org/ticket/14867 OpenWrt-Ticket] wurde wenige Monate später gelöst. Seit Chaos Calmer ist die Auswahl von Outdoor-Kanälen unter Beachtung von DFS-relevanten Signalen möglich.
Thu Jan  1 00:08:10 1970 daemon.notice netifd: radio0 (933): wlan0: IEEE 802.11 Configured channel (112) not found from the channel list of current mode (2) IEEE 802.11a
+
Thu Jan  1 00:08:10 1970 daemon.notice netifd: radio0 (933): wlan0: IEEE 802.11 Hardware does not support configured channel
+
Thu Jan  1 00:08:10 1970 daemon.notice netifd: radio0 (933): Could not select hw_mode and channel. (-3)
+
Thu Jan  1 00:08:10 1970 daemon.notice netifd: radio0 (933): wlan0: Unable to setup interface.
+
Thu Jan  1 00:08:10 1970 daemon.notice netifd: radio0 (933): hostapd_free_hapd_data: Interface wlan0 wasn't started
+
Thu Jan  1 00:08:10 1970 daemon.notice netifd: radio0 (933): cat: can't open '/var/run/wifi-phy0.pid': No such file or directory
+
Thu Jan  1 00:08:10 1970 daemon.notice netifd: radio0 (933): Command failed: Invalid argument
+
Thu Jan  1 00:08:10 1970 daemon.notice netifd: radio0 (933): Device setup failed: HOSTAPD_START_FAILED
+
  
Message "not found from the channel list of current mode" origin:
+
=== Debug-Hinweise ===
/trunk/build_dir/target-mips_34kc_uClibc-0.9.33.2/hostapd-wpad-mini/hostapd-20131120/src/ap/hw_features.c:885
+
* ath9k-DFS-Meldungen im Kernel-Log verfolgen:
 +
  echo 0x10400 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug
  
Three places in source code can generate this error. Now, find the exact place. Add more debug messages manually.
+
* ath9k-DFS-Meldungen und Pulse im Kernel-Log verfolgen (Achtung, führt zu hoher Systemlast !):
 +
  echo 0x10010400 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug ; logread -f
  
'''2nd Run'''
+
* Meldungen abschalten:
 +
  echo 0x400 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug
  
Again compiles and executed we get error
 
Thu Jan  1 00:00:49 1970 daemon.warn hostapd: wlan0: IEEE 802.11 debug oni: select_hw_mode
 
  
Therefore the reason for this error is
+
[[Category:Firmware]]
      ...
+
[[Category:WLAN Protokolle]]
      case HOSTAPD_CHAN_INVALID:
+
        default:
+
          hostapd_notify_bad_chans(iface);
+
        return -3;
+
      ...
+
new method to search for
+
  hostapd_check_chans(iface)
+

Aktuelle Version vom 10. April 2021, 09:34 Uhr

Team
Doppler-Radar-Tower.jpg
OpenWrt DFS
Treffen: unregelmäßig
Optimierung der Radarerkennung
Mitglieder:
Till W., Kai-Uwe, Björn, Martin G. (?)
Kontakt:
Crew Mailingliste


Inhaltsverzeichnis

[Bearbeiten] Problem

In OpenWrt Chaos Calmer ist es möglich, Outdoor-Kanäle auszuwählen. Beim Auftreten von DFS-relevanten Signalmustern findet ein Wechsel auf einen Indoor-Kanal statt. Ein Wechsel zurück auf einen Outdoor-Kanal findet aktuell nicht automatisch statt. DieAnzahl der DFS-Events ist zumindest bei uns, außergewöhnlich hoch, obwohl es hierfür keine offensichtliche Quelle gibt.

Beim montäglichen Vereinstreffen in der Frieda23 findet sich regelmäßig auch eine Kleingruppe für die Arbeit an der Verbesserung der DFS-Implementierung zusammen.

[Bearbeiten] Untersuchungen

[Bearbeiten] Notizen

[Bearbeiten] Aktivierung von Outdoor-Kanälen (2014, ieee80211h=1)

In OpenWrt Barrier Breaker war es nicht möglich, Outdoor-Kanäle zu aktivieren.

Die Ursache war der fehlende Eintrag ieee80211h=1 in der hostapd.conf. Das von uns eingereichte OpenWrt-Ticket wurde wenige Monate später gelöst. Seit Chaos Calmer ist die Auswahl von Outdoor-Kanälen unter Beachtung von DFS-relevanten Signalen möglich.

[Bearbeiten] Debug-Hinweise

  • ath9k-DFS-Meldungen im Kernel-Log verfolgen:
 echo 0x10400 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug 
  • ath9k-DFS-Meldungen und Pulse im Kernel-Log verfolgen (Achtung, führt zu hoher Systemlast !):
 echo 0x10010400 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug ; logread -f
  • Meldungen abschalten:
 echo 0x400 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge