#18211: Ath9k dfs bug with user reg enabled no dfs region will be set
-----------------------------+-----------------------------------
Reporter: schneider0tim@… | Owner: developers
Type: defect | Status: new
Priority: normal | Milestone: Barrier Breaker 14.07
Component: kernel | Version: Barrier Breaker 14.07
Keywords: dfs ath9k |
-----------------------------+-----------------------------------
I found this issue while enabling DFS for ETSI german outdoor-channels.
It is a custom build BB 14.07 with CONFIG_ATH_USER_REGD=y and a changed
regdb.txt to enable only german outdoor channels for 5Ghz with DFS.
output w/o modification -> after a connect try to the accesspoint.
{{{
root@OpenWrt:/sys/kernel/debug/ieee80211/phy1/ath9k# cat dfs_stats
DFS support for macVersion = 0x1c0, macRev = 0x4: enabled
Pulse detector statistics:
pulse events reported : 3
invalid pulse events : 0
DFS pulses detected : 3
Datalen discards : 0
RSSI discards : 0
BW info discards : 0
Primary channel pulses : 0
Secondary channel pulses : 0
Dual channel pulses : 0
Radar detector statistics (current DFS region: 0)
Pulse events processed : 0
Radars detected : 0
Global Pool statistics:
Pool references : 0
Pulses allocated : 0
Pulses alloc error : 0
Pulses in use : 0
Seqs. allocated : 0
Seqs. alloc error : 0
Seqs. in use : 0
root@OpenWrt:/sys/kernel/debug/ieee80211/phy1/ath9k#
}}}
as u can see DFS region = 0 == NL80211_DFS_UNSET, but my iw reg get looks
like this.
{{{
root@OpenWrt:/sys/kernel/debug/ieee80211/phy1/ath9k# iw reg get
country DE: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5470 - 5725 @ 80), (N/A, 27), (0 ms), DFS
(57240 - 65880 @ 2160), (N/A, 40), (N/A), NO-OUTDOOR
root@OpenWrt:/sys/kernel/debug/ieee80211/phy1/ath9k#
}}}
and now the following happens because of the unset dfs region.
After the ap comes up on a dfs channel and a client tries to connect it
will fail and generate an phyerr with will be handled by dfs pattern
detector. Now have a closer look at dfs_pattern_detector.c on line 270 an
you'll find
if( dpd->region == NL80211_DFS_UNSET ) return true - which means "i found
a radar" and the ap will switch to another channel ... until all channels
are markt :(
i fixed it for me quick and dirty in init.c on line 510 just chaned the
NL80211_DFS_UNSET to NL80211_DFS_ETSI. After this "patch"/"hack" the dfs
works just fine and clients can connect to the ap.
{{{
root@OpenWrt:/sys/kernel/debug/ieee80211/phy1/ath9k# cat dfs_stats
DFS support for macVersion = 0x1c0, macRev = 0x4: enabled
Pulse detector statistics:
pulse events reported : 24
invalid pulse events : 1
DFS pulses detected : 23
Datalen discards : 0
RSSI discards : 0
BW info discards : 0
Primary channel pulses : 23
Secondary channel pulses : 0
Dual channel pulses : 0
Radar detector statistics (current DFS region: 2)
Pulse events processed : 23
Radars detected : 0
Global Pool statistics:
Pool references : 7
Pulses allocated : 24
Pulses alloc error : 0
Pulses in use : 24
Seqs. allocated : 11
Seqs. alloc error : 0
Seqs. in use : 11
root@OpenWrt:/sys/kernel/debug/ieee80211/phy1/ath9k#
}}}
--
Ticket URL: <https://dev.openwrt.org/ticket/18211>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
