Just checking in to report that kmod-ath10k-ct-smallbuffers, which I use not for this problem but to save memory, also doesn't help, though the problem is exceedingly rare in our case, at least. On 21.02.3.
Did anyone try the intelligent-sounding script that openwrt-bot mentioned in the bug report link in the top post? It's not linked in that thread for some reason, perhaps because it didn't end up working out after all, though no mention of that is made. Last they were talking it sounded good.
I have been seeing this in the logs lately and I don't recall ever seeing it before. I've been up and running OpenWRT on R7800 HNYMAN for over a year. I've always got at least 10-15 wifi clients on across private and public wifi and never experience drop outs or disconnects.
Facing same issue of frequent disconnection. After experimenting with different configs issue could not be resolved. Finally, re-installed the same firmware of 18.06.4 in the device and issue resolved completely. Earlier was getting 20-30% packet drops and post re-installing the same firmware packet loss is 0%.
My device config is:
"system": "ARMv7 Processor rev 5 (v7l)",
"board_name": "8dev,jalapeno",
"target": "ipq40xx\/generic",
Might be useful to those who are facing same issue.
Though this topic appears dead, this issue manifested itself for me on OpenWrt 22.03.3 on MikroTik hAP. I have thus conducted a search of the Internet on the topic, and have found two pieces of information that don't seem to be mentioned in any of OpenWrt-related threads/bug reports/discussions:
Apple devices are notorious for this issue, across different networking equipment vendors and corresponding device firmwares, the issue being, apparently, that Apple does a "technically allowed by 802.11 but nobody actually does that because it's uncool" thing to save battery life on their devices. So it is kind of OpenWrt's fault for not supporting this 'feature', but kind of isn't.
There seems to be an idea floating around that setting DTIM [COOK] to 3 at a default beacon interval of 100 may somehow fix the issue or, at the very least, make it less severe. This idea, as far as I can tell, is solely based on information obtained from this one source, which, in turn, references another person that seemingly had a conversation with Apple support, that told them, and I quote, “set DTIM to 3 lol„ (/s, obviously)
I have set DTIM to 3 at a beacon interval of 100, while also increasing the inactivity limit to 8 hours, as advised. I will be monitoring the issue closely, and report my findings when I am able to say something conclusive.
A bit of an update. I have 2 Apple devices on my network. In the span of 9 days, there's been 24 log entries about them being deauthenticated due to inactivity, which is 1.33 per device per day. In a third of the cases, the device was reauthenticated in two minutes or less. There has been one case of reauthentication after 3 seconds, four after 15 to 30. The average time between a deauth and a reauth was 19±7 minutes (where 7 is one sigma).
I don't know how the log works exactly, that is, whether the log would contain a deauth message if the device legitimately went away without sending the router a goodbye message, but, assuming this is the case, it seems to me that most reconnections are legitimate. With erroneous reconnections only happening once in about 2.3 days per device, I think I'm happy with where I'm at.
I also observe a normal amount of deauth (not as close as originally posted here), on both the OpenWRT21 and OpenWRT22 boxes.
I have changed the settings to these:
option max_inactivity '86400'
option dtim_period '3'
option disassoc_low_ack '0'
And no skip_inactivity_poll anywhere (don't set it to 1).
I will keep this configuration for the time being. It seems that devices (including Apple ones) are disconnecting on their own, and this is what I prefer.
Did anyone ever figure out how to fix this permanently?
I am seeing the same problem with my EAP615-wall and Pixel 6.
The only real solution is to change the dtim_period as described. Some network stacks (Apple, perhaps Google) use what is legal within the specifications but a little nonstandard compared to the "rest of the world" (Windows, Android, PlayStation, Xbox, etc.). In Apple's case, it is to improve battery life by using lower power or less frequent responses.
Please try changing the dtim_period to 3 or 6. This generally resolves the issue for Apple devices and should work for Pixel.
I am still using this configuration, dtim_period set to 6 also works (could not see any notable difference). Logs show reconnections happening once per day, which seems normal.
the ct driver/firmware drains the battery on my phone way faster
compared to the upstream kernel driver/firmware.
The upstream driver/firmware also doesn't throw out those constant deauth messages.