On Thu, Nov 14, 2024 at 07:35:34PM +0000, miko...@kucharski.name wrote: > >Synopsis: random traffic stalls, initially noticed via SSH > >Category: kernel > >Environment: > System : OpenBSD 7.6 > Details : OpenBSD 7.6-current (GENERIC.MP) #426: Wed Nov 13 > 14:51:21 MST 2024 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > I had access point on OpenBSD with athn(4) on chan 6 for few > years, but finally moved to chan 64 as 2.4GHz was getting too busy. > After moving to chan 64 traffic gets often stalls. I noticed this > initially with SSH to the machine, directly over TCP session to its > egress IPv4 address, but also over a wireguard, so I am not sure are > those stalls only TCP or both UDP and TCP. I would like to stay on 5GHz > channel. For the record, while on 2.4GHz channel, I was facing those > famous, mentioned here on the list multiple times, athn0: device timeout > issues. Interesingly device timeout are gone with chan 64, but I have > now the traffic stalls. They look like a different problem, as when I > do get the stalls, exising SSH session works properly, until that TCP > stream hits the stall. >
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? 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. 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. 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.
