OpenWrt DFS: Unterschied zwischen den Versionen

Aus Opennet
Wechseln zu: Navigation, Suche
(cat)
(Debug-Hinweise)
 
(27 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
 
      ...
 
      case HOSTAPD_CHAN_INVALID:
 
        default:
 
          hostapd_notify_bad_chans(iface);
 
        return -3;
 
      ...
 
new method to search for
 
  hostapd_check_chans(iface)
 
 
In that method we have
 
      if (iface->conf->channel) {
 
                if (hostapd_is_usable_chans(iface))
 
                        return HOSTAPD_CHAN_VALID;
 
                else
 
                        return HOSTAPD_CHAN_INVALID;
 
        }
 
 
Search now for hostapd_is_usable_chans()
 
static int hostapd_is_usable_chans(struct hostapd_iface *iface)
 
{
 
        if (!hostapd_is_usable_chan(iface, iface->conf->channel, 1))
 
                return 0;
 
        if (!iface->conf->secondary_channel)
 
                return 1;
 
        return hostapd_is_usable_chan(iface, iface->conf->channel +
 
                                      iface->conf->secondary_channel * 4, 0);
 
}
 
There are two possible places to return zero.
 
 
Result of next test:
 
Thu Jan  1 00:00:19 1970 daemon.warn hostapd: wlan0: IEEE 802.11 debug oni: select_hw_mode
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (697): debug oni: test1234
 
                  debug oni: if (!hostapd_is_usable_chan(iface, iface->conf->channel, 1))wlan0: IEEE 802.11 Configured channel (112) not found from the channel list of current mode (2) IEEE 802.11a
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (697): wlan0: IEEE 802.11 debug oni: select_hw_mode
 
 
Is is the first if clause. Debug this one.
 
 
Result:
 
Thu Jan  1 00:00:18 1970 daemon.warn hostapd: wlan0: IEEE 802.11 debug oni: select_hw_mode
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: test1234debug oni: chan->chan is 36 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 40 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 44 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 48 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 52 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 56 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 60 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 64 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 100 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 104 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 108 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 116 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 120 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 124 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 128 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 132 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 136 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 140 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 149 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 153 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 157 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 161 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: chan->chan is 165 and channel is 112
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): debug oni: is_usable_chan now returns 0debug oni: if (!hostapd_is_usable_chan(iface, iface->conf->channel, 1))wlan0: IEEE 802.11 Configured channel (112) not found from the channel list of  current mode (2) IEEE 802.11a
 
Thu Jan  1 00:00:18 1970 daemon.notice netifd: radio0 (689): wlan0: IEEE 802.11 debug oni: select_hw_mode
 
 
netifd is searching for channel 112 but does not find it. We are changing the channel for futher tests to 108.
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (696): debug oni: test1234debug oni: chan->chan is 36 and channel is 108
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (696): debug oni: chan->chan is 40 and channel is 108
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (696): debug oni: chan->chan is 44 and channel is 108
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (696): debug oni: chan->chan is 48 and channel is 108
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (696): debug oni: chan->chan is 52 and channel is 108
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (696): debug oni: chan->chan is 56 and channel is 108
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (696): debug oni: chan->chan is 60 and channel is 108
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (696): debug oni: chan->chan is 64 and channel is 108
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (696): debug oni: chan->chan is 100 and channel is 108
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (696): debug oni: chan->chan is 104 and channel is 108
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (696): debug oni: chan->chan is 132 and channel is 108
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (696): debug oni: chan->chan is 136 and channel is 108
 
Thu Jan  1 00:00:19 1970 daemon.notice netifd: radio0 (696): debug oni: chan->chan is 140 and channel is 108
 
 
Again he is not finding the new channel 108. The question is now, where is the channel list created. It seems that there is an error.
 
  
 
[[Category:Firmware]]
 
[[Category:Firmware]]
 +
[[Category:WLAN Protokolle]]

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