On Thu, Nov 14, 2024 at 08:46:43PM +0000, Mikolaj Kucharski wrote: > On Thu, Nov 14, 2024 at 09:16:08PM +0100, Stefan Sperling wrote: > > > > Does netstat -W athn0 on the AP reveal any issues? > > Are any counters shown there increasing while traffic is stalled? > > Something like decryption/ccmp errors? > > pce-0041# netstat -W athn0 | grep -E 'err|ccmp' > 4 ccmp decryption errors > 1132 ccmp replayed frames > 0 cmac icv errors > 0 tkip icv errors > 0 pbac errors > > pce-0041# uptime > 8:36PM up 19:02, 1 user, load averages: 1.13, 1.00, 0.94 > > Not sure, I see `ccmp replayed frames` growing slowly on the access > point. Hard to say, are `ccmp replayed frames` growing only with stalled > traffic, but I would say not really, it just grows slowly. I would need > to observe more.
I suspect those "replays" are just duplicate frames because of retries after lost ACKs. Not unusual, especially in 11n block ack mode. > I don't have wireless or driver knowledge, but when those stalls are > happening for some TCP streams, other TCP streams between same client > and access point work well. For example, I could have multiple SSH > sessions open and some of them could get stalled, while others work. > Eventually the more I use all those working SSH sessions, they would > face the problem too, and stall. It doens't happen all at once, but > gradually. You could try forcing 11a mode. 11n block-ack does not work well on top of links prone to packet loss. And netstat -W shows you are hitting some of the errors cases in the block ack implementation which can occur when packets are lost. > > This device doesn't have firmware, so this driver has to perform > > firmware-level tasks which are tricky to debug without insights > > provided by wifi radio test equipment. The best we can do is compare > > our sources to linux ath9k and hope to spot all the bugs. It's tedious. > > Is it this code > https://github.com/torvalds/linux/tree/master/drivers/net/wireless/ath/ath9k Yes. And there is ath(4) in FreeBSD. > > What I know for a fact is that I've never seen an athn device send > > frames at Tx rates above 24 (or 36?) Mbit/s successfully with our driver. > > While this works with Linux and FreeBSD, and works with our driver on USB > > devices which, unlike the PCI ones, have firmware. This suggests some kind > > of signal distortion might be happening which breaks frames at higher > > modulation. I spent many many hours looking into this issue, but my > > investigation never really went anywhere. > > Do you have recommendation of a mini-PCIe wireless card, which could > serve as stable access point, in a PC Engines APU machine? You could try your luck with a bwfm(4) device like this one (needs a suitable adapter to fit into the minipcie slot): https://en.techinfodepot.shoutwiki.com/wiki/Dell_Wireless_1820A_(DW1820A) It also had issues when I last tried it. But there have been fixes since.
