I see no good reason for someone that has an interest in the project to come here and troll people, as such, I prefer to believe that there is an underlying reason that is preventing him to share his knowledge.
I mean, there are really bad people in the world, but you mostly see them in youtube comment boxes, where they have nothing to lose, not on project forums.
Anyway, we will soon find out.
2 Likes
At the moment, we're still at the testing stage. Also, we're at kernel v4.4.x. The OpenWRT devs will be abandoning the 4.4.x kernel after the next 17-01.x release.
To have any chance of even getting the devs to consider including the NSS drivers for the ipq806x, we would need to move to v4.14 at least. There're also extensive changes required to the netfilter stacks, which IMO will most likely not be accepted into mainline. Furthermore there's also the issue of bundling proprietary firmware blobs. So I would think it will be very challenging to have OpenWRT include the NSS drivers into mainline.
5 Likes
Turns out my 160MHz capable client (Intel 9260) is not capable of 80+80 client mode, only 160.
I tested it at 80MHz width (unable to start a contiguous 160 channel at this stage) and got 797mbps with iperf tcp.
Thanks for the update. Unable to start a contiguous channel due to DFS or another reason? Note it might take the interface a minute or so before it comes up (ie after a scan it will bring the interface up if no radar/etc found).
AFAIK, only one person here was able to broadcast a 160Mhz channel with OpenWrt using a QCA9994 (same as 9984 in R7800 but with higher operating temp), on an x86 router, and was able to break 100MBps. I'm curious to see what ipq806x (with cpu freq statically set at max) can do over wifi with 160mhz width or with 3/4 stream clients.
Unfortunately my tplink c2600 has the older qca9980 chipset, it does not support 160Mhz channels. Its seems to be abandoned; QCA didn't release a new firmware for it for 4 years, while the 9984 received many updates since release.
CT firmwares have been released for it though.. I wasn't able to get mesh working with stock ath10k, but ath10k-ct with accompanying firmware enabled mesh.
iirc qca9980 is covered by QCA988X, which would be
the last update was 5 months ago.
1 Like
DFS.
It's the typical DFS cac_start_fail() message.
I traced out the code yesterday and the error occurs after hostapd hands over to the driver.
I'll need to get some debugging info and send it to greearb and see if he can assist.
I tested all other DFS widths (20-80MHz) and they're fine.
Interestingly, 80+80 also fails if either (or both) sections are in DFS space.
1 Like
Has this mac80211 problem been resolved? I've seen that there was a new commit related to mac80211 and wonder if this issue was addressed.
Not yet, to my knowledge. I built a few days ago ath10k (old) version of master, and it still crashed.
the -ct version works normally.
I've raised a bug report for this (I'm seeing the same thing on an x86 QCA9984 build):
https://bugs.openwrt.org/index.php?do=details&task_id=2427&order=id&sort=desc
I added there a short comment that it is an x86 duplicate (with x86 evidence) of my earlier bug report FS#2414
Thanks, I searched "mac80211" before I raised mine but evidently it only searches the titles by default 
I've also tried using a master branch build with kmod-ath10k-ct, but a PS4 connected via wifi seems to have major problems using any online functionality with this build. With a 19.07 branch build with kmod-ath10k, it works as expected.
Another patch for everyone. Fixing the DFS cac_start_fail() when starting 160 or 80+80MHz channels on the QCA9984 with ath10k-ct + ct firmware.
--- a/dev/null
+++ b/package/kernel/ath10k-ct/patches/699-enable_dfs_higher_widths_10-4_4-19.patch
@@ -0,0 +0,11 @@
+--- a/ath10k-4.19/mac.c
++++ b/ath10k-4.19/mac.c
+@@ -9392,6 +9392,8 @@ static struct ieee80211_iface_combinatio
+ .radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT) |
+ BIT(NL80211_CHAN_WIDTH_20) |
+ BIT(NL80211_CHAN_WIDTH_40) |
++ BIT(NL80211_CHAN_WIDTH_80P80) |
++ BIT(NL80211_CHAN_WIDTH_160) |
+ BIT(NL80211_CHAN_WIDTH_80),
+ #endif
+ },
Mon Aug 12 22:10:52 2019 daemon.notice hostapd: wlan0: DFS-CAC-START freq=5200 chan=40 sec_chan=-1, width=2, seg0=50, seg1=0, cac_time=60s
Mon Aug 12 22:13:04 2019 daemon.notice hostapd: wlan0: DFS-CAC-COMPLETED success=1 freq=5200 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5250 cf2=0
the key line which i guess no one else spotted was
total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }
which means that mac80211 wasn't allowing the DFS check at the higher bandwidths as it was an invalid combination. After this patch:
total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }
When in 160MHz mode, it switches to 2SS mode so you only get 1733mbps max speed anyway, so if you have a 4SS capable client, leaving it at 80MHz outside of DFS is probably going to be just as good, and give you less DFS headaches. Still, the router is capable of doing it, so we should have the option.
And that should be the big "no 160MHz on this device" mystery solved I reckon...
4 Likes
Please report that also on the ath10k-ct bug tracker for @greearb
Already did, although i think he was sure the error was external to the driver so may have dismissed the error report.
Either way I'm sure it will be on a backlog somewhere for him.
Edit: he has picked it up.
Could you do some benches to determine real throughput with 160mhz?
please set cpu to performance governer before you start (or set frequency manually to max).
Happy to, although one thing I've just realised is that I'm not sure of the correct testing methodology to produce best/real world results.
Typically I use iperf between a wired LAN client and a Wi-Fi client, but this limits me to a max of 1gbps and so my previous result was maybe invalid.
My thoughts are to run multiple iperf streams from multiple LAN devices to the same Wi-Fi client to try and saturate it, does this seem valid to anyone?
Maybe you can try running iperf3 on the router itself?
All of my previous experience tells me this will drag the performance down
Typically yes. Normally iperf should be outside if testing routing performance. If testing raw speed for WiFi, I would testing running iperf3 in the router probably is a valid test case. I would think the R7800 should have enough CPU power to handle this.
Seems true enough after experimenting.
Looks like i read the wrong numbers off the iperf test last time too, here's all the tests i ran.
Router as iperf server:
AP 80+80. Client 80. 2SS. 866mbps link speed.
Client send: 445mbps
Client receive: 130mbps
AP 160. Client 160. 2SS. 1404mbps link speed.
Client send: 332mbps
Client receive: 139mbps
AP 80. Client 80. 2SS. 866mbps link speed.
Client send: 445mbps
Client receive: 130mbps
PC (LAN client) as iperf server:
AP 80+80. Client 80. 2SS. 866mbps link speed.
Client send: 400mbps
Client receive: 214mbps
AP 160. Client 160. 2SS. 1404mbps link speed.
Client send: 337mbps
Client receive: 207mbps
AP 80. Client 80. 2SS. 866mbps link speed.
Client send: 407mbps
Client receive: 123mbps
Note hugely different speeds across any of the settings.
I've only got 1 3SS device i can test with (WRT32X) and i currently can't be bothered getting it set up for testing.
1 Like