On Fri, Nov 15, 2024 at 11:52:30AM +0100, Stefan Sperling wrote: > 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. >
I switched to 11a mode and that really helped. Thanks Stefan for the tip. I am using it for approximately two weeks and the connecton over Wi-Fi are way more stable in 11a mode. -- Regards, Mikolaj
