I’ve not checked the default configuration recently but is the default to skip DFS channels? If so, why? You’re allowed to use DFS channels as long as the device carries out the CAC check. In the UK, on the AC range, the only non-DFS channel at the bottom end has the lowest TX power.
If you live near a war zone, there will be plenty of actual radars around (even if you’re hundreds of kms away from current front line) … so CAC might never produce a working DFS channel. So it’s better to avoid them right from the start by configuring some non-DFS channels.
I’ve got a Xiaomi Redmi Note Pro 12 and yes, I’ve had quirks with it as well. Normally I have the 2.4GHz and 5GHz SSIDs set to the same but for testing/experimentation, I’ve sometimes given them different names. On more than one occasion, the 5GHz SSID doesn’t show at all on the mobile. Turning Wi-Fi off and back on causes it to reappear.
That said, I’ve not done any serious testing on other Wi-Fi network to determine whether this is a quirk of the phone or is limited to my hAP ax2. I do get the feeling that because I focus a lot more on my home network that I’m more aware of issues.
I’ve just opened the Wi-Fi settings on my Xiaomi and I can’t see “Middle Earth 5G” or “TV Box 5G” (both are from my hAP ax2):
However, literally as I was looking at the screen, the 5GHz networks appeared from my hAP ax2:
Whilst I was typing this/sorting out screenshots, my mobile went to sleep. On turning it on again, the 5GHz networks have disappeared from the hAP ax2 and as of typing, have not reappeared… left it another minute and they’ve appeared.
I’ve got another vendor’s AP in the cellar. I’ll dig that out and do some side by side tests but there is definitely something weird going on with the Xiaomi mobile.
I’ve had a quick look at the logs and spotted this “private-5g detect LAN” - what does that mean? Did I read somewhere in this topic or elsewhere something about detect LAN??
Later… came across several posts about problems with Redmi Note 12 and Wi-Fi 6 so maybe I’ll not waste my time:
This particular post suggests turning off randomised MAC address which I’ve just done to see if it makes any difference. However, this setting is for connected networks. I’ve never connected to “TV Box 5G” on my mobile and that disappears as well.
Later… no, not made any difference. Was sat there looking aimlessly at my mobile and the hAP ax2 5GHz SSIDs disappeared.
Did you try to disable scan throttling? It’s enabled by default
Never mind, wrong post.
I’ve been monitoring this all this afternoon. I’ve got my Teclast Android tablet with mobile phone next to it. Running WiFi Analyser which has an option to keep the screen on. Just seen it happen in front of my eyes - the Middle Earth 5G network disappeared on my Xiaomi mobile phone but persists on the tablet. Additional observation: the neighbour’s Virgin Media router on 5180 doesn’t disappear at the same time. 5 minutes later and it hasn’t re-appeared on my mobile.
Apologies for the screenshot quality - had to use my webcam.
I’m not sure this is related to the topic of this post or whether I should spin it out into a separate post. The core difference between the two devices is tablet is Wi-Fi 5 only whereas mobile is Wi-Fi 6.
Another interesting observation. I’m currently doing some work in the lab so I’ve also got a hAP ac lite connected on the bench. That also isn’t appearing until I turn Wi-Fi on and off on the mobile:
So… with this Xiaomi mobile, both hAP ac lite AND hAP ax2 5GHz is unstable but the neighbouring 5GHz Virgin Media access point is rock solid. In addition, it might not be a problem with Wi-Fi 6 on the hAP ax2 as it’s occurring on the hAP ac lite.
I do have the password for my neighbours Wi-Fi so will carry on tomorrow with the same set-up but connected to there. I also think I’ve got a TP-Link Wi-Fi 5 AP somewhere for further tests.
Last post for tonight. Whilst somebody might say the problem lies with the Xiaomi mobile as the tablet doesn’t exhibit the same problem. I could buy into that except that doesn’t explain why the same issue doesn’t occur with the neighbours Virgin Media Wi-Fi 5 router. It never disappears on the mobile.
Whit out seeing logs I can only guess that Xiaomi phone just blacklists MT AP for some reason. Does AP logs say that Xiaomi phone have lost connection multiple times?
I’ve done a bit more testing today and I’m going to say “ignore my posts about Xiaomi mobile” in the context of this thread, i.e. something to do with SA Query Timeout. It’s a red herring and I only went down this rabbit hole as somebody else mentioned a Xiaomi mobile.
I’ve just connected up a TP-Link TL-WA1201 access point and it’s doing exactly the same thing. In fact, it’s doing it far more frequently than the MT access point. This is clearly some quirk with the Xiaomi Redmi Note Pro 12 and Wi-Fi 5 - or more widely the MediaTek soc. Google that and you open up an even bigger can or worms. Consider how ubiquitous Wi-Fi is on the planet, I’m surprised there are so many quirks everywhere.
Since you mention Xiaomi mobiles:
My Xiaomi 12 Pro on “HyperOS 1.0.18” acutally has similar issues, but it’s about all Wi-Fi scanning being incredibly slow.
For example, just 3 Networks showed up. 2 of which where my ax3 and another was some 2.4ghz from the neighbor.
Usually there’s at least 5 Networks from the neighbors with 2.4 and 5ghz.
With my ax3 itself being 3 at 2.4 and 5ghz
And i had another issue recently just with the Xiaomi:
It didnt want to connect to the ax3s 2.4ghz. Didnt test it with anything else.
The phone did say connected but the ax3 never said the same thing.
Any other device didn’t have issues connecting to the wifi. Including iPhones, smart home crap and some laptops.
Reboot of BOTH phone and router fixed the issue.
Does your wifi country mach on AP and phone? It will cause MT chips to disconnect, also adding BSSID on temp ignore list.
A user should have been able to get support to reproduce the bug:
http://forum.mikrotik.com/t/hap-ax3-random-wireless-disconnects/176477/1
I got recently two hap ax2 devices set up with capsman and found out a similar problem with Xiaomi device - this is Mi Box media streaming box. All seems to be well on 5 GHz, but on 2,4 GHz it hands on refuses to connect no matter what settings are used for 2,4 GHz radio. It worked without problems on 2,4 GHz with hap ac and old legacy driver.
Xiaomi is WPA2 non-ax device and is capable to connect to 5 GHz SSID with WPA2/WPA3 mixed mode, but on 2,4 GHz nothing works - not even disabling ax and WPA3. Same behaviour is on 7.18.2 and 7.19beta8. Bad thing is that there’s nothing in logs after unsuccessful attempts.
I am now experiencing “SA query timeout” - but it is logged by iwd on Linux Kernel 5.15 and Intel AX200. On the AP it logged a “disconnected. signal too strong”. I already reported this to Mikrotik support and I hope I can help to nail down the issue.
Have a HAP AX2 and MI TV stick 4k at home and have had to create an SSID with 5ghz only to stop it trying to connect to 2.4ghz and fail.
On a related note, I had to create a virtual network with just “WPA PSK” enabled as my Android TV Box won’t connect when type is set to WPA2 or WPA3 PSK. But it does work at both 2.4GHz and 5GHz.
Can’t you just make it static from the router then add it to the access list ?
Thats what I do with stuff thats pretty static tbh.
Extremely Disappointed - SA Query Timeout Bug Still Not Fixed After 10+ Months
I’m posting this with significant frustration. This WiFi SA Query timeout issue has been plaguing the community for over 10 months since RouterOS 7.15 was released, and we’re still stuck on 7.14.3 to have stable WiFi.
As a network professional who has invested heavily in MikroTik infrastructure, it’s unacceptable that such a fundamental WiFi stability issue remains unresolved through multiple major releases (7.15, 7.16, 7.17, 7.18, and now 7.19). This forces production networks to remain on an outdated RouterOS version, missing security updates and new features.
I’ve just submitted a comprehensive bug report to support@mikrotik.com and wanted to share it here for community visibility:
Subject: WiFi SA Query Timeout Issue with Google Cast/Chromecast Devices - RouterOS >7.14.3
Device Information:Core Firewall: MikroTik CCR2116-12G-4S+ (CF001) - RouterOS 7.19.1
Access Points:
AP001: MikroTik C53UiG+5HPaxD2HPaxD (Attic) - RouterOS 7.14.3
AP002: MikroTik C53UiG+5HPaxD2HPaxD (Basement) - RouterOS 7.14.3
AP003: MikroTik C53UiG+5HPaxD2HPaxD (Garage) - RouterOS 7.14.3
Problem Description:
Experiencing frequent WiFi disconnections with “SA Query timeout” errors affecting all Google Cast/Chromecast enabled devices when running RouterOS versions newer than 7.14.3. The issue does NOT occur on RouterOS 7.14.3. This is a widely reported issue in forum thread: http://forum.mikrotik.com/t/not-responding-f-k-a-sa-query-timeout/168864/1
Affected Google Cast Devices:
Google Nest Audio speakers (multiple)
Google Nest Mini speakers (multiple)
Chromecast with Google TV devices
Google Home speakers
Any device with Chromecast functionality
Current WiFi Configuration (CF001 - CAPsMan Controller):
/interface wifi channel
add band=2ghz-ax disabled=no frequency=2412 name="2.4GHz AX 1" secondary-frequency=disabled width=20mhz
add band=2ghz-ax disabled=no frequency=2437 name="2.4GHz AX 6" secondary-frequency=disabled width=20mhz
add band=2ghz-ax disabled=no frequency=2462 name="2.4GHz AX 11" secondary-frequency=disabled width=20mhz
add band=5ghz-ax disabled=no frequency=5180 name="5.0GHz AX 36" secondary-frequency=disabled width=20/40/80mhz
add band=5ghz-ax disabled=no frequency=5745 name="5.0GHz AX 149" secondary-frequency=disabled width=20/40/80mhz
add band=5ghz-ax disabled=no frequency=5805 name="5.0GHz AX 161" secondary-frequency=disabled width=20/40/80mhz
/interface wifi datapath
add bridge=BR_Main bridge-cost=10 disabled=no name="datapath1 main"
add bridge=BR_Guest bridge-cost=20000 client-isolation=yes disabled=no name="datapath2 guest"
/interface wifi security
add authentication-types=wpa2-psk disabled=no ft=yes ft-over-ds=yes management-protection=allowed name=WiFi_Security_Main wps=disable
add authentication-types=wpa2-psk disabled=no ft=yes ft-over-ds=yes management-protection=allowed name=WiFi_Security_Guest wps=disable
/interface wifi configuration
add beacon-interval=200ms channel="2.4GHz AX 1" country="United States" datapath="datapath1 main" disabled=no dtim-period=2 mode=ap multicast-enhance=enabled name=WiFi_AP003_Garage_2_4G_Ch1 security=WiFi_Security_Main ssid=TrekGalactic_2.4Ghz
add beacon-interval=200ms channel="2.4GHz AX 11" country="United States" datapath="datapath1 main" disabled=no dtim-period=2 mode=ap multicast-enhance=enabled name=WiFi_AP002_Basement_2_4G_Ch11 security=WiFi_Security_Main ssid=TrekGalactic_2.4Ghz
add beacon-interval=200ms channel="2.4GHz AX 6" country="United States" datapath="datapath1 main" disabled=no dtim-period=2 mode=ap multicast-enhance=enabled name=WiFi_AP001_Attic_2_4G_Ch6 security=WiFi_Security_Main ssid=TrekGalactic_2.4Ghz
add beacon-interval=200ms channel="5.0GHz AX 149" country="United States" datapath="datapath1 main" disabled=no dtim-period=2 mode=ap multicast-enhance=enabled name=WiFi_AP001_Attic_5G_Ch149 security=WiFi_Security_Main ssid=TrekGalactic_5.0Ghz
add beacon-interval=200ms channel="5.0GHz AX 36" country="United States" datapath="datapath1 main" disabled=no dtim-period=2 mode=ap multicast-enhance=enabled name=WiFi_AP002_Basement_5G_Ch36 security=WiFi_Security_Main ssid=TrekGalactic_5.0Ghz
add beacon-interval=200ms channel="5.0GHz AX 161" country="United States" datapath="datapath1 main" disabled=no dtim-period=2 mode=ap multicast-enhance=enabled name=WiFi_AP003_Garage_5G_Ch161 security=WiFi_Security_Main ssid=TrekGalactic_5.0Ghz
/interface wifi capsman
set ca-certificate=auto certificate=auto enabled=yes interfaces=BR_Main require-peer-certificate=no upgrade-policy=suggest-same-versionSymptoms:
Frequent “SA Query timeout” messages in AP logs
Simultaneous packet loss across all WiFi devices when Google Cast devices are streaming
WiFi devices maintain DHCP leases but lose connectivity
Issue severity increases with more Google Cast devices connected
Problem occurs on both 2.4GHz and 5GHz bands
Affects other non-Google devices when Google devices are active
Issue does NOT occur with same configuration on RouterOS 7.14.3
Reproducible Test Case:
Upgrade any AP from RouterOS 7.14.3 to 7.15.x or newer
Connect Google Cast/Chromecast devices to WiFi
Begin streaming content (Spotify, Netflix, YouTube) to these devices
Within minutes to hours, observe:
“SA Query timeout” entries in AP logs
Simultaneous connectivity drops across network
Packet loss when pinging affected devices
Troubleshooting Already Attempted:
Netinstall with factory defaults - issue persists
Disabled management protection - no improvement
Separate virtual SSIDs for Google devices - same behavior
Different security settings (WPA2-only) - no change
Tested on different radio bands separately - issue persists
Minimal configuration with only 2 devices - still reproduces
Various WiFi settings (connect-priority, dtim-period, etc.) - no improvementVersion Test Results:
RouterOS 7.14.3: STABLE - No SA Query timeouts
RouterOS 7.15.x through 7.19.x: All exhibit SA Query timeout issues
All tested beta versions: Still problematic
Network Architecture:Internet → GW001(Lumen 500/500) → CF001(Core Firewall/CAPsMan) →
CS001/CS002(Core Switches) → DS001-009(Distribution Switches) →
AP001-003(Access Points) → WiFi Clients
Community Forum Reference:
This issue is extensively documented in MikroTik Forum thread: http://forum.mikrotik.com/t/not-responding-f-k-a-sa-query-timeout/168864/1
Multiple users confirm identical behavior with Google Cast devices
Issue appears to be introduced with newer Qualcomm WiFi drivers after 7.14.3
Users report ticket SUP-174626 relates to this issue
Specific Request:Can MikroTik engineering reproduce this issue using Google Cast/Chromecast devices?
What is the root cause of the SA Query timeout regression after 7.14.3?
What is the ETA for a permanent fix?Are there any interim workarounds beyond staying on 7.14.3?
Additional Information:
I can provide supout.rif files from both working (7.14.3) and problematic (newer) configurations
Available for additional testing if engineering needs specific test scenarios
This appears to be a regression in the Qualcomm WiFi driver introduced after 7.14.3The issue is 100% reproducible with Google Cast devices and current configuration
Support Files Available:
supout.rif from CF001 (CAPsMan controller)
supout.rif from individual APs running 7.14.3 (working)
supout.rif from APs after upgrade (problematic) - can generate upon request
Please prioritize this issue as it affects a significant number of users and forces staying on an older RouterOS version to maintain WiFi stability.
Extremely Disappointed - SA Query Timeout Bug Still Not Fixed After 10+ Months
I postulated elsewhere that this suggests that there is a bug in the driver which Mikrotik can’t fix as they don’t control the driver. Or worse it’s a hardware fault in the AX chipset. Let’s hope it’s not the later. But if it’s a driver problem, then Mirotik been at the mercy of Qualcomm and their fix schedule isn’t ideal. I probably know the business reason but it does mean they’re exposed. Are other manufacturers in the same boat?