Some in the last thread like @prwood@Limentinus@tew42 (apologies if I left anyone out) mentioned the excessive and rather mysterious kernel logging issue:
kern.info kernel: [49696.489344] ath10k_pci 0000:00:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
Archer C7 v2, v4, v5 were affected, but also at least some others on the affected Qualcomm Atheros chipsets, like Turris Omnia.
Since the release notes mention nothing about this, I assume the issue is still present in this release, yes? If so, it would be nice to know if it matters. For example, are you seeing wireless issues because of it?
I am also seeing this on a C7 v3 (using v2). Was going to comment on the 22.03.4 release thread, only to be surprised with the sudden .5 release!
My symptoms are an occasional instance of this, a few times an hour or less, to every few seconds, but not long instances. It seems to coincide with a couple of devices that have chronic issues with the group key handshake, they sometimes fail the 4 attempts, then get disconnected. This happened in the past, usually with the device just reconnecting and rekeying successfully.
Now, it seems to be when this ath10k error message pops up.
Difference in my case, I am seeing momentary loss of internet connection. Haven't made a solid determination, but it seems to be associated with the time when the error pops up. Wifi devices are connected, but have no internet connection, for a few to a few 10's of seconds, then it comes back. All the devices I've seen this are on the ath10k/5ghz radio.
I still haven't fully tested if this issue isn't a main router issue, or if the ath9k/2.4ghz radio isn't also showing net dropouts at the same time. I did migrate my separate x86 router to 22.03.4 a while earlier, but hadn't seen the net drops till I moved the C7 AP to 22.03.4
I'll change a few settings that are modified from stock, in the C7, to see if that has influence, then will probably try 22.03.5
What could I say? - do you see the glass half full or half empty?
Regardless Openwrt, it is just a kernel module driver for armv7l architecture. It is widely used also in Raspberrypi and similar and still brcmfmac is developing for linux kernel.
So I see the hope!
Moreover Openwrt 22.03.5 has 5.10.x kernel while vanilla is 6.3.x, so still there is some space for growing.
Particular in this instability: it probably could be some kernel parameters or requirement to stick with concreate firmware for 4366b-pcie.
It is still possible to even bypass the issue installing good watchdog just in time restarting wifi to have pretty acceptable level of stability.
Also may be it could be possible to adopt brcmfmac, but I have no clue what exactly functionality is on the side of 4366 firmware, also have never seen something as release history for all Broadcom firmare for BRCM4366 chip.
May be even opposite it should be backported older brcmfmac when it was stable.
I am currently analyzing how stable it is, hoping that just "monitor properly (this should be a part of openwrt) of radio0 and radio1 and restart it automatically" approach should be good enough with less efforts. Worse (do not see for this enough reasons) - to adopt brcmfmac kernel module to make it proper working.
And solution is easy - replace firmware, do in time wifi down radioX && wifi up radioX in worse time - full reboot. So at least - even with buggy brcmfmac+FW it could be bypassed properly in the release of Openwrt and hope with less efforts!
PS: I also bought in 2022 especially DIR-885L HW1 as compatible with Openwrt and with excellent hardware part, so not going to give up, and will probably with in time will build custom firmware from scratch or will create dedicated topic for this, if instability will be so critical that could not be bypassed by restart radio interfaces via script.
auc -y updated an Archer C7 v4. adblock didn't reload properly on boot, it appears DNS wasn't alive yet, so an adblock.sh reload fixed it after checking everything else out.
That's helpful. All I can add is that it also seems to happen with the two recent 21.02 updates (C7 v2), though in that case there's only light usage (so relatively infrequent instances of the recurring events, explaining why I didn't notice it) and it's not my home router so I can't really tell if it's manifesting in any problematic way as it seems to do in your case.
But maybe there's a clue in the fact that both sets of maintenance releases show this. That does make some sense, since both the v21 and v22 updates had overlap in terms of changes.
Interesting... I haven't seen this error much, if at all, before updating to the 22.03.4 release. I was fooling around with non stock settings as well, (WPA2/3, different timeouts for rekey and dissasociate, longer beacon and DTIM time) but have reverted to stock and just WPA2... with the errors still appearing.
After doing that last night... with a bit of time on it, it's looking like it's settled down to the pattern I've been seeing. I have my rekey set back to 3600 (1hr) and the dissasociate time to 900 (15min). What I'm seeing is every connected station rekeys on the hour, and many times, there's a lazy one that fails, and gets dissasociated. Thats when this error shows up. Though, not every time, not the same device, and it varies on getting disconnected, just disassociated, etc. I need to get familiar with the stages of connecting and verifying, and what that looks like in log entries... But overall, its happening pretty much after the end of the global rekey.
Haven't done the upgrade yet, though I agree that due to the (apparent) lack of changes in the wifi or ath10k areas would suggest that it doesn't change things. We'll see.
I also feel that we should get a specialized thread going for this in one of the other sections, and get this off the service release thread. A few reports are appropriate, but I don't want to dig as deep here, as I'd want to...
do you see the glass half full or half empty?
