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.
(few minutes later)
pce-0041# netstat -W athn0 | awk '$1 > 0'
ieee80211 on athn0:
6 input packet duplicates discarded
18 input packets from unassociated station discarded
2 input packets with mismatched channel
2014 input packets with mismatched ssid
7 input deauthentication packets
90 input eapol-key packets
10 input eapol-key packets replayed
57 output packets failed for no nodes
2557 nodes timed out
4 ccmp decryption errors
1317 ccmp replayed frames
23 new input block ack agreements
16 input frames below block ack window start
5 input frames above block ack window end
3 input block ack window slides
53 duplicate input block ack frames
232 expected input block ack frames never arrived
48 input block ack window gaps timed out
> Generally, I believe this driver has calibration and/or heat issues.
> It is possible that as the chip warms up the radio moves slightly off
> channel and would need recalibration to function correctly. But this
> is just a theory. There are many other possible reasons why traffic might
> stall, e.g. radar or other interference that's not being compensated for.
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.
> 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
> 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?
--
Regards,
Mikolaj
