5 GHZ band has rea lissues with DFS channels

[RafcioRS]

Describe the bug

I use DFS channel as non-DFS ones are extremely crowded where I live, and OpenWRT has serious issues with DFS channels. One thing, it's not able to scan the 5 GHz band, when the radio is active. When the radio goes down (and that's the second bug), the scan works.
There has to be a better way of handling DFS channels. I've been using Tomato firmware for many years and has never had the wireless (that was always on DFS channel) go down. OpenWRT firmware has an annoying issue that the 5 GHz radio goes down and doesn't recover on its own. The radio has to manually restarted, or the system rebooted. This happens several times a week.

Here are the log entries related to the issue.
Sat Aug 5 13:53:37 2023 daemon.notice hostapd: wlan0: DFS-RADAR-DETECTED freq=5500 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5530 cf2=0
Sat Aug 5 13:53:37 2023 daemon.notice hostapd: dfs_downgrade_bandwidth: no DFS channels left, waiting for NOP to finish
Sat Aug 5 13:53:37 2023 daemon.notice hostapd: wlan0: AP-DISABLED
Sat Aug 5 13:53:37 2023 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 2c:8d:b1:59:b4:88
Sat Aug 5 13:53:37 2023 daemon.err hostapd: 20/40 MHz: center segment 0 (=106) and center freq 1 (=5510) not in sync
Sat Aug 5 13:53:37 2023 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Sat Aug 5 13:53:37 2023 daemon.notice netifd: Network device 'wlan0' link is down
Sat Aug 5 13:53:37 2023 kern.info kernel: [262715.982457] device wlan0 left promiscuous mode
Sat Aug 5 13:53:37 2023 kern.info kernel: [262715.987388] br-lan: port 2(wlan0) entered disabled state
Sat Aug 5 13:53:37 2023 kern.info kernel: [262715.998425] ath10k_pci 0000:00:00.0: mac flush null vif, drop 0 queues 0xffff
Sat Aug 5 13:53:37 2023 daemon.notice hostapd: wlan0: interface state ENABLED->DISABLED
Sat Aug 5 13:53:38 2023 kern.warn kernel: [262717.119159] ath10k_pci 0000:00:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256
Sat Aug 5 13:53:38 2023 kern.info kernel: [262717.136885] ath10k_pci 0000:00:00.0: wmi print 'P 128 V 8 T 410'
Sat Aug 5 13:53:38 2023 kern.info kernel: [262717.143928] ath10k_pci 0000:00:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0 ct-sta: 0'
Sat Aug 5 13:53:38 2023 kern.info kernel: [262717.152356] ath10k_pci 0000:00:00.0: wmi print 'alloc rem: 24984 iram: 38672'
Sat Aug 5 13:53:38 2023 kern.warn kernel: [262717.221367] ath10k_pci 0000:00:00.0: pdev param 0 not supported by firmware
Sat Aug 5 13:53:38 2023 kern.info kernel: [262717.236701] ath10k_pci 0000:00:00.0: rts threshold -1
Sat Aug 5 13:53:38 2023 kern.info kernel: [262717.252509] br-lan: port 2(wlan0) entered blocking state
Sat Aug 5 13:53:38 2023 kern.info kernel: [262717.258158] br-lan: port 2(wlan0) entered disabled state
Sat Aug 5 13:53:38 2023 kern.info kernel: [262717.264115] device wlan0 entered promiscuous mode
Sat Aug 5 13:53:38 2023 daemon.notice hostapd: wlan0: interface state DISABLED->COUNTRY_UPDATE
Sat Aug 5 13:53:38 2023 kern.debug kernel: [262717.271939] ath: EEPROM regdomain: 0x82be
Sat Aug 5 13:53:38 2023 kern.debug kernel: [262717.276286] ath: EEPROM indicates we should expect a country code
Sat Aug 5 13:53:38 2023 kern.debug kernel: [262717.282812] ath: doing EEPROM country->regdmn map search
Sat Aug 5 13:53:38 2023 kern.debug kernel: [262717.288417] ath: country maps to regdmn code: 0x3b
Sat Aug 5 13:53:38 2023 kern.debug kernel: [262717.293448] ath: Country alpha2 being used: SG
Sat Aug 5 13:53:38 2023 kern.debug kernel: [262717.298207] ath: Regpair used: 0x3b
Sat Aug 5 13:53:38 2023 kern.debug kernel: [262717.301923] ath: regdomain 0x82be dynamically updated by user
Sat Aug 5 13:53:38 2023 kern.debug kernel: [262717.308097] ath: EEPROM regdomain: 0x82be
Sat Aug 5 13:53:38 2023 kern.debug kernel: [262717.312326] ath: EEPROM indicates we should expect a country code
Sat Aug 5 13:53:38 2023 kern.debug kernel: [262717.318822] ath: doing EEPROM country->regdmn map search
Sat Aug 5 13:53:38 2023 kern.debug kernel: [262717.324471] ath: country maps to regdmn code: 0x3b
Sat Aug 5 13:53:38 2023 kern.debug kernel: [262717.329648] ath: Country alpha2 being used: SG
Sat Aug 5 13:53:38 2023 kern.debug kernel: [262717.334411] ath: Regpair used: 0x3b
Sat Aug 5 13:53:38 2023 kern.debug kernel: [262717.338139] ath: regdomain 0x82be dynamically updated by user
Sat Aug 5 13:53:38 2023 daemon.notice hostapd: wlan0: interface state COUNTRY_UPDATE->HT_SCAN
Sat Aug 5 13:53:41 2023 daemon.notice hostapd: wlan0: interface state HT_SCAN->DFS
Sat Aug 5 13:53:41 2023 daemon.notice hostapd: wlan0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=0, seg0=106, seg1=0, cac_time=60s
Sat Aug 5 13:53:41 2023 daemon.err hostapd: 20/40 MHz: center segment 0 (=106) and center freq 1 (=5510) not in sync
Sat Aug 5 13:53:41 2023 daemon.err hostapd: Can't set freq params
Sat Aug 5 13:53:41 2023 daemon.err hostapd: DFS start_dfs_cac() failed, -1
Sat Aug 5 13:53:41 2023 daemon.err hostapd: Interface initialization failed
Sat Aug 5 13:53:41 2023 daemon.notice hostapd: wlan0: interface state DFS->DISABLED
Sat Aug 5 13:53:41 2023 daemon.notice hostapd: wlan0: AP-DISABLED

Now that the 5 GHZ radio is down (the icon is solid) the wireless scan of that band is working, otherwise nothing is shown. That's really strange.
There probably needs to be a way to enter a fallback (non-DFS?) channel, when the radio has to vacate the specified DFS one, and a periodic scan to figure out when the radio can return to the "primary" channel. That would be my idea about how that issue should be handled.

OpenWrt version

r20028-43d71ad93e

OpenWrt target/subtarget

ath79/generic

Device

TP-Link Archer A7 v5

Image kind

Official downloaded image

Steps to reproduce

No response

Actual behaviour

No response

Expected behaviour

No response

Additional info

No response

Diffconfig

No response

Terms

• I am reporting an issue for OpenWrt, not an unsupported fork.

[brada4]

You need to set channel to automatic for DFS to hop to "better" one when radar is detected.

hostapd will not jump off non-DFS channel unless forced manually.

You might want to tune ACS like giving occupied channels less precedence (more bias value)
https://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf#n198
or
option min_tx_power '21' to avoid weaker channels, or other options above it in example file to select subjectively less occupied DFS channels with more precedence over occupied non-dfs.
https://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf#n240

2nd receiver is certainly present in ath10k, and likely scans radar and measures occupancy in unused channels (though this activity is unnecessary since you do not intend to switch channel by configuration)

You can see passive scan data with iw dev wlan0 survey dump without pinching radio hardware.

[hnyman]

Here are the log entries related to the issue.
Sat Aug 5 13:53:37 2023 daemon.notice hostapd: wlan0: DFS-RADAR-DETECTED freq=5500 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5530 cf2=0
Sat Aug 5 13:53:37 2023 daemon.notice hostapd: dfs_downgrade_bandwidth: no DFS channels left, waiting for NOP to finish

As radio thinks that it detects radar traffic, it needs to change channel. If there are no alternative channels configured ("no DFS channels left"), the radio needs to turn off.

You could provide a list of alternative channels to try with the "channels" option. (i additional to the main "channel" options)
Example and discussion in forum, e.g.

https://forum.openwrt.org/t/5-ghz-wlan-craps-out-upon-radar-detection-start-dfs-cac-failed/71018/12

(Looking at the hostapd docs, it actually seems that channels options (=chanlist in hostapd) should be space separated:

Channel list restriction. This option allows hostapd to select one of the
provided channels when a channel should be automatically selected.
Channel list can be provided as range using hyphen ('-') or individual
channels can be specified by space (' ') separated values
Default: all channels allowed in selected hw_mode
chanlist=100 104 108 112 116
chanlist=1 6 11-13

[brada4]

The "soft" option to bias channels based on preference is needed to have non-dfs available in case all DFS channels get radar signal and you still need connectivity. Usually law goes like to stop transmitting within seconds from radar detection for an hour on that frequency. Restart would actually break the rules for short blink of internet.

[hhasert]

I use a cron job to check Wifi every few hours and restart the channels when they are down. I think one of my neighbours has some equipment that jams the 5Ghz when in use and OpenWrt thinks it is radar :-). The script looks like :

if [[ $(ip link | grep 'wlan0'| awk '{print $11}') != 'UP' ]] then $(wifi down radio0; sleep 2; wifi reload radio0; sleep 2; wifi up radio0

[brada4]

What I am saying (tailored to SG domain) - prefer DFS 20dBm a bit, and 27dBm more over busy non-DFS channels.
Then wait few typical radar detect cycles to ensure it stays in DFS (note its 40MHz spacing, will work for both 80MHz and for unlikley 40MHz fallback)
option acs_chan_bias '52:0.9 60:0.9 100:0.8 108:0.8 116:0.8 124:0.8 132:0.8 140:0.8'

[RafcioRS]

Thanks for all the suggestions. There are still issues. Perhaps I've made a mistake reporting 2 bugs in one report. Assuming that the 5 GHz radio can be configured not to go down when possible radar signal is detected (which I believe is false positive anyway), there is still a bug with Channel Analysis for 5 GHz band showing only Local Interface and no other radios when local radio is operating normally. When it's disabled after detecting a radar signal, it then mysteriously works correctly, showing dozens of entries for 5 GHz band.
That's a bug for sure IMHO.

[RafcioRS]

You need to set channel to automatic for DFS to hop to "better" one when radar is detected.

hostapd will not jump off non-DFS channel unless forced manually.

You might want to tune ACS like giving occupied channels less precedence (more bias value) https://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf#n198 or option min_tx_power '21' to avoid weaker channels, or other options above it in example file to select subjectively less occupied DFS channels with more precedence over occupied non-dfs. https://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf#n240

2nd receiver is certainly present in ath10k, and likely scans radar and measures occupancy in unused channels (though this activity is unnecessary since you do not intend to switch channel by configuration)

You can see passive scan data with iw dev wlan0 survey dump without pinching radio hardware.

Where is the config file to edit? I couldn't find hostapd.conf file anywhere. I've found /tmp/run/hostapd-phy0.conf that seems to have the config options for 5 GHz radio, but that file seems to be dynamically generated, so editing it doesn't make sense. For any config change suggestions, please list the full path to the file that I need to edit. Thanks.

[brada4]

/etc/config/wireless section with country code

[brada4]

It is a driver limitation. iw dev wlan0 scan passive force-ap succeds to read survey data

[RafcioRS]

I use a cron job to check Wifi every few hours and restart the channels when they are down. I think one of my neighbours has some equipment that jams the 5Ghz when in use and OpenWrt thinks it is radar :-). The script looks like :

if [[ $(ip link | grep 'wlan0'| awk '{print $11}') != 'UP' ]] then $(wifi down radio0; sleep 2; wifi reload radio0; sleep 2; wifi up radio0

That script seems to be missing the closing parentheses, but regardless of that, there seems to be something else missing as it looks like it's waiting for something.

root@Archer_A7:/tmp/run# if [[ $(ip link | grep 'wlan0'| awk '{print $11}') != 'UP' ]] then $(wifi down radio0; sleep
2; wifi reload radio0; sleep 2; wifi up radio0
> ^C

That has to be terminated with Ctrl-C.
I've run it in a separate shell as it seems that cron doesn't like ceratain things that you normally enter on a command line, so the outcome of that looks like it's waiting for another "then" statement.

root@Archer_A7:~# sh -c "if [[ $(ip link | grep 'wlan0' | awk '{print $11}') != 'UP' ]] then $(wifi down radio0; sleep 2
; wifi reload radio0; sleep 2; wifi up radio0)"
sh: syntax error: unexpected end of file (expecting "then")

[RafcioRS]

It is a driver limitation. iw dev wlan0 scan passive force-ap succeds to read survey data

Not quite.

root@Archer_A7:/tmp/run# iw dev wlan0 scan passive force-ap
Usage: iw [options] dev scan [-u] [freq ] [duration ] [ies <hex as 00:11:..>] [meshid ] [lowpri,flush,ap-force,duration-mandatory] [randomise[=/]] [ssid |passive]

Scan on the given frequencies and probe for the given SSIDs
(or wildcard if not given) unless passive scanning is requested.
If -u is specified print unknown data in the scan results.
Specified (vendor) IEs must be well-formed.

Options:
--debug enable netlink debugging
root@Archer_A7:/tmp/run# iw dev wlan0 scan passive
command failed: Resource busy (-16)

[RafcioRS]

And after correcting the syntax, it still fails to produce the necessary output.

root@Archer_A7:/etc/config# iw dev wlan0 scan ap-force passive
command failed: Resource busy (-16)

[brada4]

C7 works, though mesh node not ap

[brada4]

Wave1 ath10k does not support scanning in AP mode as per https://ath10k.infradead.narkive.com/qMsEgGSi/support-for-scan-while-in-ap-mode-and-offchannel-while-in-ap-mode (10.2 firmware may work but likely will crash due to its old age)

Radar detection is not complete outside ETSI as per
https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/configuration#configuring_hostapd

In human language:
passive survey (channel fill minus AP names) is closest you can get to customary survey
radar will be detected on first suspicious signal, not 3-5 repetitions of it