I thought that I solved the problem with the intel ax200 chipset with the no SPMS parameter but unfortunately I still had disconnects. I have switched to a Realtek based card for 22 euros, in particular based on the chipset 8852BE and all my problems are gone and the signal is a little better. For me, it was not worth spending so much time diagnosing the problem insted of buying a new card. I hope the problem can be fixed for intel cards.
Well replacing the WLAN adapter in my company issued laptop is not the way I want to go. My Intel card is working perfectly well with every other AP I tried. Also some Lenovos simply refuse WLAN adapters which they don´t get shipped with (don´t ask me why, dumbness of Lenovos policies?).
Also I have one more suspect, but I could not fully confirm it yet: my sons Laptop has a Realtek 8822CE. He complained a lot last summer about the connectivity to the CAPax. So maybe this bug doesn´t only affect Intel cards.
It doesn’t. Realtek’s 88xx are affected as well.
Side note, these series have a history of problems with APs powered by (some) Mediatek chipsets. Ubiquiti Nano HDs were a total disaster with Realtek clients.
So I thought at first the same was happening with new Qualcomm firmware (ROS > 7.14.3)… until we experienced same issues with Intel AXs and discovered how global that problem is..
Thanks @dmfr! But to me it looks like not all RTL88xx are affected, as @pdrsks wrote, that his 8852BE works flawlessly.
Still good to know the issues are complicated at does not only affect MT.
Same exactly WIFI adapter here, Intel Wifi 6E AX211 on a Lenovo L13
Thanks @MrRobotdev, so until now we have:
Intel WiFi 6E AX211
Realtek 8822CE
Those are affected, if WPA3 is used.
Any other chipsets?
Thoroughly tested by me and affected when WPA3 is used
Intel WiFi 6E AX201
Intel WiFi 6E AX210
Intel® WiFi 7 BE200
and of course Intel WiFi 6E AX211
Bad news, below is my last update to support ticket
After more testing in living conditions with :
- 7.17beta2 or 7.16 stable
- wpa2 only + management protection disabled
- additionally, band steering disabled
- various chipsets (Realtek 8821, Intel AX201, Google Pixel 4/6)
it seems that unfortunately the problem is deeper than management protection frames and/or wpa3.
Unexplained connectivity drops still happens under some conditions.
Example :
- 2 (or more) stations with busy, continuous traffic (ex UDP or websocket video streaming)
- other stations almost idle
- at some point, at the same time :
-
- connectivity breaks on one of the active stations…
- -… and connectivity breaks as well on one (or more) random idle station(s)
- affected stations will eventually reconnect after several attempts
- no relevant messages in log, except disconnect / connect
Revert to 7.14.3, no more issues. Stress tests such as above always pass.
“SA Query timeout” might be one of the symptoms when mgmt protection enabled, but it is definitely not the root cause.
As of today any potential workaround mentionned does not entirely clear the problem, except revert to 7.14.3
This is exactly my observation with same settings tried.
For example yesterday i tried to watch movie and my LG OLED and Samsung soundbar disconnected with connection lost 4 times in 2 hours while i try to watch a movie…
Most of the time router kicks all clients same time with query timeout (or connection lost on 7.17)
Zero problems on 7.14.3.
I think at this point Mikrotik should just revert new Qualcomm drivers they added in 7.15 until they figure whats wrong…
it is known to be issues since many months. not even reverted in 7.17beta2. so won’t happen.
Thanks for your inputs!
So we have issues with WPA3 with the new WIFI AX Drivers at least with the following chipsets:
Intel WiFi 6E AX201
Intel WiFi 6E AX210
Intel WiFi 6E AX211
Intel WiFi 7 BE200
Realtek 8822CE
Unfortunately these are very common chipsets!
I hope MT wakes up and gives us some hints? This must affect lots of users, MT looses lots of reputation here. @Normis ?
Intel ax200 also reported by some.
“SA query timeout” is a symptom, not the root cause.
The problem occurs as well with wpa2 + no mgmt protection.
WPA3 just makes is more obvious.
I am not sure chipset vendor / model really matters anyway.
Reviewing logs from controller I’ve seen “drops” from Iphone, Pixel, Intel AX, Realtek 88xx…
One thing, the drop have a tendancy to occur on APs with more than one active (significant traffic) station.
It never happens if there’s only one station registered to the AP.
dunno bout significant traffic but this! every second-third time i’m on a zoom call wifi drops! ax211 lap ↔ hap ax3
Sounds like a very similar configuration to me. Same hAP ax2, only with Windows laptops.
Huhh, not easy to catch and we are probably talking about multiple bugs.
I never had issues with my previous laptop (gave that back, so Wifi chipset unknown) and my mobiles. Only my new laptop seems to be affected and my childs laptop. My previous laptop had Win10 my current one and also my childs laptop has Win11 installed.
I have WPA3 enabled.
Unfortunately I do only spend time around there where my CAPax is installed every 2-3Weeks, so I can´t test right now, but I´ll check tomorrow with WPA2/WPA3 and swithcing off/on management frame protection and then will roll back to 7.14.3, probably will try 7.17betaX as well.
I also have a few Linux laptops, I´ll check them too!
So for me those chips under Win11 are affected with 7.15.x-7.16 on my CAPax.
Intel WiFi 6E AX211
Realtek 8822CE
Thanks everyone for the infos!
If 7.14.3 works, why Mikrotik just revert the relevant drivers to that state until they figure out what is going on?
STOP feature development and start bug fix guys… simple as that…
What is the meaning of moving forward to 7.17 or 7.18 if we cannot connect with our business laptops to wifi?
HP also affected
The same issue on AX3, so using 7.14.3 version with Factory Firmware 7.15.2. 
Very sad issue.
7.17beta2
Unfortunately, the problem still exists, only the name has changed
Intel WiFi 6E AX211
*) wifi - re-word the "SA Query timeout" log message to "not responding";
We might have to rename this thread 