On 26/11/2019 00:34, Hauke Mehrtens wrote: > It looks like there is a throughput problem with ath10k-ct on QCA9984, > https://bugs.openwrt.org/index.php?do=details&task_id=2593 > there are multiple reports in the Forum. > > For me QCA9880 on a BTHH5A with ath10k-ct on 5GHz works in openwrt 19.07 > The AP can do 180 MBit/s TX and only 40 Mbit/s RX over about 8m with a > wall in between with sae-mixed to a Intel iwl8265. > It is also very close to 40MBit/s not much changing the lowest I saw in > about 30 outputs from iperf3 was 38.8 MBit/s and them highest 41.2 MBit/s
I am seeing the same low RX with a qca988x AP and an 8265 client. This did not happen earlier this year. I first noticed this on September 5th, but I don't have known good commit hash. The problem goes away when I disable 802.11w. Without 802.11w, I get 300-400Mbps TX and RX. Do you have any other clients than the 8265 to test this? Ben suggested this might be an issue on the 8265 end, and to use a sniffer to look into block-ack setup packets: 18|20:29:01< greearb__> sniff the block-ack setup packets, make sure client sends them encrypted (ie, if you see them open-auth encoded, sender is issue) 18|20:30:51< greearb__> you will really want to spend some quality time with a sniffer to see if block-acks are working or not, and if BA setup frames are properly encrypted Unfortunately the device with the 8265 is my only Linux client with 5GHz and convenient sniffing support. Some of the Raspberry Pi boards seem to support it with nexmon, but that looks overcomplicated. Maybe I could try with my DIR860L, but so far I have not been able to do so. If you have the equipment for it, maybe you can give it a try? Other than that, ath10k-ct is extremely stable on all my APs. Something that cannot be said about ath10k. With the right combination of clients, it was crashing within 1 day of uptime, while still sending beacons, thus clients still trying to associate to the 5GHz network. WiFi experience with stock ath10k was simply abysmal, almost downright unusable. It was suggested that this was due to the use of 802.11w, but disabling 802.11w is not a solution, and in my opinion not even an option, especially with WPA3. Stijn _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel