VHT160 broken in master (R7800, ath10k-ct ?)

Somewhere between r14984 and r15026 VHT160 stopped working (at least on R7800) and is broken still in build r15199. Regardless whether channel is requiring DFS or not hostapd returns the following error:

hostapd: DFS start_dfs_cac() failed, -1

I know @dotcomcoolie-free observed similar behavior but also wih R7800. I am wondering if any other device has that issue.

1 Like

Can anyone turn this into git hashes for me please? I don't have an OpenWrt buildroot available at the moment.

well I have this in my notes... not sure if it's any use but it's in the timeframe...

    NOTE:        -@237-r1499~6-6e9b707ee2 uqmi/qmi dhcp patches
                 -also prev build wireless seems better... probably patch from around 20201122~+- non-pi-specific

which is likely 80b531614beab477c642cfdfef8dc6238c58f00
or the ones around it...
$ ./scripts/getver.sh r14984
d36999389890fb952fc7cc8c0db8e1bbb671af12
$ git log -1 --oneline d369993898
d369993898 scripts: download.pl: retry download using filename

$ ./scripts/getver.sh r15026
89854d38349220bbbd9796ca59da4f4c551d5e99
$ git log -1 --oneline 89854d3834
89854d3834 ath10k-ct: update to latest version
1 Like

Might it be the one below to blame?

93bbd998aa696a5e9cff51131854b78b30c0af34 hostapd: enter DFS state if no available channel is found
$ ./scripts/getver.sh 93bbd998aa6
r13895-93bbd998aa

Much earlier. That would be in July 2020

commit 93bbd998aa696a5e9cff51131854b78b30c0af34
Author: David Bauer <mail@david-bauer.net>
Date:   Mon Jul 20 15:08:19 2020 +0200

    hostapd: enter DFS state if no available channel is found

Your previously indicated range was mid-November...

$ git log d36999389 | head -n 5
commit d36999389890fb952fc7cc8c0db8e1bbb671af12
Author: David Bauer <mail@david-bauer.net>
Date:   Wed Nov 18 16:02:23 2020 +0100

    scripts: download.pl: retry download using filename

$ git log 89854d383 | head -n 5
commit 89854d38349220bbbd9796ca59da4f4c551d5e99
Author: Álvaro Fernández Rojas <noltari@gmail.com>
Date:   Mon Nov 23 15:09:45 2020 +0100

    ath10k-ct: update to latest version

Assuming that your initial regression rang ewas correct, I might much easier believe this as a possible culprit:
ath10k-ct: update to latest version

Might be interesting to see if it fails also with the mainline ath10k, or only with ath10k-ct

1 Like

I compiled a version for R7800 with mainline ath10k. (instead of the default "-ct").
master-r15207-c29f6121fd-20201213-ath10k
It is available from my R7800 community build dir.

It does allow VHT160 configured radio to come up, although for me only with 80 width:

Sun Dec 13 22:17:58 2020 kern.info kernel: [  287.114450] br-lan: port 3(wlan0) entered blocking state
Sun Dec 13 22:17:58 2020 kern.info kernel: [  287.114510] br-lan: port 3(wlan0) entered disabled state
Sun Dec 13 22:17:58 2020 kern.info kernel: [  287.119589] device wlan0 entered promiscuous mode
Sun Dec 13 22:19:02 2020 daemon.warn hostapd: Can't set DFS state for freq 5180 MHz
Sun Dec 13 22:19:02 2020 daemon.warn hostapd: Can't set DFS state for freq 5200 MHz
Sun Dec 13 22:19:02 2020 daemon.warn hostapd: Can't set DFS state for freq 5220 MHz
Sun Dec 13 22:19:02 2020 daemon.warn hostapd: Can't set DFS state for freq 5240 MHz
Sun Dec 13 22:19:02 2020 kern.info kernel: [  351.232872] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Sun Dec 13 22:19:02 2020 kern.info kernel: [  351.233039] br-lan: port 3(wlan0) entered blocking state
Sun Dec 13 22:19:02 2020 kern.info kernel: [  351.238296] br-lan: port 3(wlan0) entered forwarding state
Sun Dec 13 22:19:02 2020 daemon.notice netifd: Network device 'wlan0' link is up

As it failed with ath10k-ct, it might quite well be something related to the ath10k-ct bump by @Noltari which I mentioned above as a possibility.

Have compiled ath10k build myself and indeed there is no issue:

Connected to 8a:3c:ad:11:51:24 (on wlp2s0)
	SSID: OpenWRT
	freq: 5180
	RX: 195632 bytes (620 packets)
	TX: 85847 bytes (385 packets)
	signal: -54 dBm
	rx bitrate: 780.0 MBit/s VHT-MCS 8 160MHz short GI VHT-NSS 1
	tx bitrate: 400.0 MBit/s VHT-MCS 9 40MHz short GI VHT-NSS 2

	bss flags:	short-slot-time
	dtim period:	5
	beacon int:	101

BTW in my case hostapd log is stating DFS for 80Mhz exactly as for you but both Luci and client report 160MHz:

Dec 13 22:31:25 ap hostapd: Can't set DFS state for freq 5180 MHz
Dec 13 22:31:25 ap hostapd: Can't set DFS state for freq 5200 MHz
Dec 13 22:31:25 ap hostapd: Can't set DFS state for freq 5220 MHz
Dec 13 22:31:25 ap hostapd: Can't set DFS state for freq 5240 MHz

I wanted to confirm that the build referenced here with the mainline ath10k firmware worked for me whereas the other recent builds did not. Thanks for help sorting this out.

@greearb FYI