I acquired a used AX3600 and got most recent OpenWRT snapshot ( OpenWrt SNAPSHOT r22496-d98c8fc06d )
Right now I did a speed test with 2 devices (Intel Dual Band Wireless AC 8265 + 1x Google Pixel 3a, both Wifi 5 afaik) connected to it. In the middle of the speed test, one wifi connection (Google Pixel 3A) dropped and came back a few seconds later while the second wifi connection (Intel Wifi 8265) only stopped transmitting any data for a few seconds.
Logfile:
(the phone, ae:... and 96:... has mac randomization turned on, the computer is d4:... and did not even create any log entries in that time frame). There is no further errors above or below, wifi works again afterwards.. AP Settings:
(after I opened the package with the AX3600, i immediately thought its test-ssid must be named the_beast)
I somehow got the impression this AP is production ready - it does not seem so Can I do something?
I figured something out:
When I run speedtest (dslreports.com) on PC and ookla on phone and then turn off the wifi on the phone, I get an error: [12912.077164] ath11k c000000.wifi: failed to flush transmit queue, data pkts pending 5
and at the same time there is no throughput on the computer for a few seconds.
Thanks for pointing to that "bug", i have my doubts if that is related... As I don't have the build environment set up, I cannot easily try it out If someone provides a sysupgrade, I am happy to test. Otherwise I guess it might be firmware related so we are in the hands of the gods?
I disabled beamforming and BSS coloring again. Could still reproduce, disconnect phone during speedtest means computer doesn't get any packets for 2-3 seconds.
I'd be also interested in knowing if others just don't notice this problem or if it is something new? To me, this makes wifi unusable as I don't want interruptions in video conferences Is there somewhere an archive for older snapshots available?
For now, I might get 2x Xiaomi AX3200 which seems to me the device with the best price tag (in germany, where you even pay 58€ for this)
Wow, I downgraded to
r22446-1c552eb44d (2023-03-28)
from:
and the problem here is gone. While from the changelog I wouldn't know what the cause could be I wonder if pointing somebody to the regression might be useful?
With r22496-d98c8fc06d i have the problem that disconnecting a client under load (my google phone running "ookla speedtest") stopped any traffic on the wifi for a few seconds (see opening post).
I could 100% reliably reproduce this.
After downgrading to r22446-1c552eb44d from the link above (my own build failed..) which looks like it is the corresponding snapshot build + a few packages not related to wifi, I can not reproduce the problem anymore: I can disconnect my phone while doing a speedtest repeatedly and other clients are not impacted nor do I get a transmit queue flush failure in the log.
the ath11k patch that restores 160 MHz support (but I don't think this is the cause as I tried on 80 MHz with and without beamforming)
then there is this: d54c91bd9ab3c54ee06923eafbd67047816a37e4 patch that says it is fixing vulnerabilities but contains a whole bunch of patches to mac80211 including some "flush the tx buffer on client disconnect" which sounds like it could be connected to my problem
Unfortunately I don't really have a build system setup and on my laptop it takes ages, but I could try to bisect the responsible commit...
Problem is how ath11k works with buffer... I need to check what data ieee80211 provide
The tx buffer in ath11k is global so there isn't a clear separation of buffer related to one client... Doing that change is doable but require a big rework of the driver... Good thing is that there is already a problem in how the tx ring works so I already had to mess with that.
I retested current master and the issues are gone. I am a bit confused if fw upgrade 2.9 fixed it as well as I thought I tested before. Anyway, current snapshot runs great, I easily get 600 Mbps with my 2-stream AC laptop behind 1 wall... Nice Thanks for all the great work and I am happy that somehow this radio is also working great.
When taking the "802.11ax speed problems" that some people describe with the mediatek radios into account, I wonder if we should actually recommend the AX3600 more - great pricepoint & performance.