[OpenWrt-Devel] OpenWrt 19.07 status

[Hauke Mehrtens]

On 11/26/19 10:44 AM, Stijn Tintel wrote:
> 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.

The BTHH5A uses the VR9 / VRX200, a Lantiq/Intel MIPS 35Kec BE SoC.

I connected my IPQ4019 to the QCA9880 and have the same results.
IPQ4019 -> QCA9880 ~> 200 MBit/s
QCA9880 -> IPQ4019 ~>  36 MBit/s

I also sniffed the traffic between my iwl8265 and the QCA9880 with the
IPQ4019.

I monitored a iperf3 session where I send 46.6 MBytes in 28 seconds from
the QCA9880 to the iwl8265 with about 40 MBit/s, I captured 44389
packets with the QCA9880 in monitor mode.

19.5% (8651) of the packets are RTS packets send by the QCA9880, 0.1%
(35) of the packets are RTS packets send by other devices.

I do not see the data send by the QCA9880 probably because the iwl8265
is closer.

I haven't seen any differences when deactivating 802.11w or WPA3.

Block Ack are send unencrypted.

The IPQ4019 and the QCA9880 used OpenWrt 19.07-rc2 with ath10k-ct.

Hauke

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20191206/f7965228/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel