"not responding" - f.k.a. SA Query timeout

Fri Jan 17, 2025 9:08 pm

Finally support hinting Detect Internet is no good

mndtrp · Fri Jan 17, 2025 10:32 pm

that works for you!
Mikrotk answered me by mail
Please check these items in interface settings.

Thanks!

Been there, done that. Didn't help

I'm also actively troubleshooting this with support. Probably sent 20+ .rif files. And so far it looks like it is a combination of ROS > 7.14.3 and Google Nest Hubs/Speakers that breaks Mikrotik WIFI intermittently. The more Nest devices I have connected, the worse it gets.

jimmys01 · Fri Jan 17, 2025 10:44 pm

The more Nest devices I have connected, the worse it gets.

I have like a billion IT devices connected. But those are working fine, just my xiaomi phones have the issue.

litvcom · Sat Jan 18, 2025 1:27 am

I see that 7.17 has been released and I immediately decided to check this thread to see if anything has been fixed. And I understand that there are no changes. Oh, cool.

Jef61 · Sat Jan 18, 2025 2:03 pm

I'm also actively troubleshooting this with support. Probably sent 20+ .rif files. And so far it looks like it is a combination of ROS > 7.14.3 and Google Nest Hubs/Speakers that breaks Mikrotik WIFI intermittently. The more Nest devices I have connected, the worse it gets.

Yes, I have 4 Google Nest Speakers and only with version 7.14.3 the WiFi is stable.
But I have given up, bought AP's from another vendor, rock stable now.

mman1982 · Sat Jan 18, 2025 8:14 pm

Experiencing the same problem with 7.16 with CapXL ac and Cap ac too. Before upgrade it.worked with the same devices/phones..

pfyod · Tue Jan 21, 2025 6:17 pm

I do not have google nest speakers, but I do have 3 xiaomi google home speakers and I also experience wifi instability (and "SA Query timeout" spam in logs) with anything newer than 7.14.3.

From v7.18beta2 changelog:

*) wifi - avoid excessive re-transmission of SA Query action frames;

Anyone brave enough to try to see if it fixes things?

vaskoss · Tue Jan 21, 2025 6:19 pm

7.18 beta

*) wifi - avoid excessive re-transmission of SA Query action frames

It's worth a try ?

mndtrp · Tue Jan 21, 2025 7:10 pm

7.18 beta

*) wifi - avoid excessive re-transmission of SA Query action frames

It's worth a try ?

Why not

Testing now. 12+ hours in. There is no noticeable improvement, still get simultaneous packet drops while pinging Google Nest Speakers and other Chromecast enabled devices.

*Edited multiple times. Things looked good in the beginning, but the issues returned after adding the Google Nest Speakers and other Chromecast enabled devices to my HAP ax2. Got confirmation from MK support that my issue is not addressed in beta2 release.

alibloke · Wed Jan 22, 2025 1:37 am

WPA3 + fast roaming works for me now

arnisfreimanis · Wed Jan 22, 2025 7:24 pm

Same here. A lot of connection losts of all kind of devices (mainly random PC's, phones). I saw somewhere that WPA2 without management protection could help as a tmp solution, but that either does not work for me. And the worst thing is that I bought 7 wAP AX for a client and there is no way to roll back to 7.14.x as the factory firmware is something like 7.15.x

alibloke · Wed Jan 22, 2025 8:13 pm

Have you tried setting connection-priority = 0/1?

What about rOS 7.18b2? There are several wifi improvements there.

arnisfreimanis · Wed Jan 22, 2025 10:06 pm

Yes, connection priority 0/1 and today upgraded to beta, still the same. However, I think it was worse before the upgrade.

vmsh0 · Thu Jan 23, 2025 12:04 pm

I'm seeing this on the hAP ax3, can confirm that latest beta doesn't fix. If MikroTik support thinks I could help in some way, I ask them to please contact me.

I have a thread here: viewtopic.php?p=1120829

erlinden · Thu Jan 23, 2025 12:06 pm

I'm seeing this on the hAP ax3, can confirm that latest beta doesn't fix. If MikroTik support thinks I could help in some way, I ask them to please contact me.

Create supout file and share with support.

Meanwhile, please feel free to share your config to have a sanity check on it:

/export file=anynameyoulike

Remove serial and any other pirvate info, post ebtween code tags by using the </> button.

pfyod · Thu Jan 23, 2025 5:22 pm

@arnisfreimanis: do you also have google nest / home / chromecast devices in your network?

MichalPospichal · Fri Jan 24, 2025 7:48 pm

I attempted to isolate the problem and done many configuration tests, but with no success.

I am able to easily replicate the issue within a few minutes with ONLY 2 devices connected - my phone Moto Edge30 Fusion and WiiM Mini streamer (this one does NOT have chromecast functionality). cAP ax, I only had 5GHz radio active, single SSID with basic default wifi config (apart from group key update of 1H), with WPA2 PSK only, and CCMP ciphers/group encryption.
WiiM is streaming a radio, and within a few minutes it starts to drop out, at which moment my phone disconnects and reconnects with SA query timeout. This periodically repeats several times an hour.

If I add Wiim Ultra streamer to the mix, I get the same dropouts on either of the streamers even without the phone connected, so in this case when Mini is streaming, Ultra disconnects and Mini drops the audio out for a moment. And vice versa, basically the device that is currently streaming does not seem to disconnect but it clearly loses connection for a short time and the idle device disconnects/reconnects.
If there is only 1 device connected it seems to be stable, at least for a few hours, from what I tested. It is like 2+ devices connected at the same time cannot stand each other.

I understand there are people that have no issues with new WiFi qc drivers, but this problem is so widely reported by many people that it cannot be a configuration error, more so when in 7.14 it reportedly works fine. Mikrotik should really look into this in priority, because there must be some serious problem somewhere.
(btw I also created a ticket and provided my suport.rif file).

grzegorzb · Sat Jan 25, 2025 2:44 pm

Unfortunately, I have already lost hope of fixing the WiFi disconnection problem. After all, the problem has been known for more than a year and Mikrotik does nothing about it. Instead, it offers a useless winbox 4 and other “gadgets” and the reported problems remain uncorrected. This is a pity, because other equipment manufacturers such as Tp-Link benefit from this. In the past, in hotels, guesthouses and other public premises, the majority of WiFi network was implemented by Mikrotik, but now I see Omada equipment being installed in its place. No one professionally dealing with networks will push for the problems that Mikrotik guarantees.

infabo · Sat Jan 25, 2025 2:50 pm

It seems you've accidentally pasted your comment twice. That said, desktop application development (such as Winbox) and web development (like the Webfig redesign) are entirely separate disciplines from software development for embedded devices (such as those running RouterOS on MikroTik hardware). These efforts do not interfere with one another. My 2 cents.

arnisfreimanis · Sat Jan 25, 2025 6:43 pm

@arnisfreimanis: do you also have google nest / home / chromecast devices in your network?

Nope, none of that.

erlinden · Sat Jan 25, 2025 9:48 pm

Unfortunately, I have already lost hope of fixing the WiFi disconnection problem.

Did you have a look at the past changelogs?

After all, the problem has been known for more than a year and Mikrotik does nothing about it.

v7.14.3 was introduced April the 17th, 2024. After this release, a new(er) driver of Qualcom was introduced that caused problems for some users. Have been there, did a lot of tweaking and have zero problems currently using v7.18beta2 (and the same since all 7.16.x versions there were made available).

In the past, in hotels, guesthouses and other public premises, the majority of WiFi network was implemented by Mikrotik, but now I see Omada equipment being installed in its place. No one professionally dealing with networks will push for the problems that Mikrotik guarantees.

Can you please provide numbers?

To be honest, a new user with only 2 posts saying it has lost faith...either provide some constructive feedback or request for help. But stop complaining and talking about other brand(s).

pfyod · Mon Jan 27, 2025 8:29 am

v7.14.3 was introduced April the 17th, 2024. After this release, a new(er) driver of Qualcom was introduced that caused problems for some users. Have been there, did a lot of tweaking and have zero problems currently using v7.18beta2 (and the same since all 7.16.x versions there were made available).

Good for you. There are plenty of people here for whom the only fix that works is a rollback to 17.4.3. Someone posted above that they can reproduce the issue with a fresh / default config and just two devices. The "I just switched off WPA3 / set connect priority / ... and it works for me, don't know what y'all talking about!" crowd is just distracting from the real issue.

infabo · Mon Jan 27, 2025 8:44 am

It would be beneficial to all to report these issues to Mikrotik support - instead on whining here. This is a community topic. Of course there will be comments like "I dont have this issue" just because this is not a Mikrotik support thread. It is a open discussion.

arnisfreimanis · Mon Jan 27, 2025 9:05 am

v7.14.3 was introduced April the 17th, 2024. After this release, a new(er) driver of Qualcom was introduced that caused problems for some users. Have been there, did a lot of tweaking and have zero problems currently using v7.18beta2 (and the same since all 7.16.x versions there were made available).

So.. where was the problem? How to tweak things right?

erlinden · Mon Jan 27, 2025 10:00 am

I'm not saying this is "right", at least it is working perfectly for me:

# 2025-01-27 08:41:54 by RouterOS 7.18beta2
# software id = 3EBJ-1MI6
#
# model = RB4011iGS+
# serial number = #############
/interface wifi channel
add band=2ghz-ax disabled=no frequency=2412,2437,2462 name=CHAN-2G \
    reselect-interval=18h..1d skip-dfs-channels=10min-cac width=20mhz
add band=5ghz-ax disabled=no frequency=5250-5710 name=CHAN-5G \
    reselect-interval=4h..8h skip-dfs-channels=10min-cac width=20/40/80mhz
/interface wifi datapath
add bridge=bridge-LAN disabled=no name=Datapath vlan-id=1
/interface wifi security
add authentication-types=wpa2-psk connect-priority=0/1 disabled=no ft=yes \
    ft-over-ds=yes multi-passphrase-group=SSID name=SSID-PPSK wps=disable
/interface wifi configuration
add channel=CHAN-2G country=Netherlands datapath=Datapath disabled=no \
    dtim-period=3 mode=ap multicast-enhance=enabled name=SSID-CONF-2G \
    security=SSID-PPSK ssid=SSID tx-power=9
add channel=CHAN-5G country=Netherlands datapath=Datapath disabled=no \
    dtim-period=3 mode=ap multicast-enhance=enabled name=SSID-CONF-5G \
    security=SSID-PPSK ssid=SSID tx-power=24
/interface wifi capsman
set ca-certificate=auto enabled=yes interfaces=MGT-VLAN package-path=\
    /packages require-peer-certificate=no upgrade-policy=none
/interface wifi provisioning
add action=create-dynamic-enabled disabled=no master-configuration=\
    SSID-CONF-5G name-format=%I supported-bands=5ghz-ax
add action=create-dynamic-enabled disabled=no master-configuration=\
    SSID-CONF-2G name-format=%I supported-bands=2ghz-ax
/interface wifi security multi-passphrase
add disabled=no group=SSID isolation=no passphrase=passphrase-50 vlan-id=50
add disabled=no group=SSID isolation=yes passphrase=passphrase-51 vlan-id=51

For context:
Two VLAN's, ID 50 for home and ID 51 for Guest.
PPSK to have a single SSID, WPA2-PSK as that is only supported for PPSK:
https://help.mikrotik.com/docs/spaces/R ... properties
For fast roaming ft=yes and ft-over-ds=yes (for devices that support FT) and connect-priority=0/1 for those who don't.
Devices are (all the usual) brands like Samsung, Apple, Noika, HP, Microsoft, Dell, etc.
There are three wAP AX CAP's (but also working just fine for cAP AX).

lubomirs · Mon Jan 27, 2025 10:41 am

"...authentication-types=wpa2-psk..."

I don't want to use WPA2. . .

Mon Jan 27, 2025 10:42 am

v7.14.3 was introduced April the 17th, 2024. After this release, a new(er) driver of Qualcom was introduced that caused problems for some users. Have been there, did a lot of tweaking and have zero problems currently using v7.18beta2 (and the same since all 7.16.x versions there were made available).
Good for you. There are plenty of people here for whom the only fix that works is a rollback to 17.4.3. Someone posted above that they can reproduce the issue with a fresh / default config and just two devices. The "I just switched off WPA3 / set connect priority / ... and it works for me, don't know what y'all talking about!" crowd is just distracting from the real issue.

7.18beta also has no improvement for you? then your issue might be caused by something completely different.
from this topic we have seen many people who join in on the "me too", but the issue was related to something else.
please make a full report of the issue with RIF file from 7.18beta, logs from client device, etc. and email to support@mikrotik.com

maigonis · Tue Jan 28, 2025 2:49 pm

I tested again wap ax as STA on latest beta, still get deauth frames (beta on all MT devices). As I get random reason codes, I'm trying to collect them all (for fun).

Test was exactly the same as mentioned is SUP-174626 ticket, connection session was active about 6 days.

image.png

blondasek · Mon Feb 03, 2025 1:10 am

[...]
I found the reason for the loss of signal in all gadgets with a router. Private wi-fi address mode was enabled on iphone settings in static address mode. Turning off this mode doesn't result in loss of signal from the router during two day. Additionally turned off Wi-Fi Assist mode in cellular data.

true

As result when STA receives deauth frame it actually leaves AP as 802.11 standards require, and we get log entry "connection lost", or "sa query timeout" on AP. This affects all wave2 lineup devices afaik.
I have reported this to support.

EDIT:
unfortunately it did not fix the problem. Still dropping the signal. Waiting for Mikrotik action.

Larsa · Mon Feb 03, 2025 1:10 pm

@blondasek, @maigonis - This is just a user forum. If you haven't already, please email a support.rif to support@mikrotik.com.

KindlyMan · Sat Feb 15, 2025 12:47 pm

@blondasek, @maigonis - This is just a user forum. If you haven't already, please email a support.rif to support@mikrotik.com.

I sent them files three times, and they gave me recommendations on some settings. I made them, but the problem was not solved.

erlinden · Sat Feb 15, 2025 1:07 pm

I sent them files three times, and they gave me recommendations on some settings. I made them, but the problem was not solved.

Have you shared your config here on the forum already? Would like to have a look at it, if possible.

mman1982 · Sat Feb 15, 2025 2:28 pm

It seems 7.18beta6 solved for me,after 1 days usage looks like it works.

Good for you. There are plenty of people here for whom the only fix that works is a rollback to 17.4.3. Someone posted above that they can reproduce the issue with a fresh / default config and just two devices. The "I just switched off WPA3 / set connect priority / ... and it works for me, don't know what y'all talking about!" crowd is just distracting from the real issue.
7.18beta also has no improvement for you? then your issue might be caused by something completely different.
from this topic we have seen many people who join in on the "me too", but the issue was related to something else.
please make a full report of the issue with RIF file from 7.18beta, logs from client device, etc. and email to support@mikrotik.com

mndtrp · Mon Feb 17, 2025 5:57 pm

It seems 7.18beta6 solved for me,after 1 days usage looks like it works.

7.18beta also has no improvement for you? then your issue might be caused by something completely different.
from this topic we have seen many people who join in on the "me too", but the issue was related to something else.
please make a full report of the issue with RIF file from 7.18beta, logs from client device, etc. and email to support@mikrotik.com

No improvement with the latest beta (7.18beta6).
https://imgur.com/a/iFbIkgI
All WIFI devices break simultaneously.
*SIGH*
And yes, I have been through the hoops with support with rif's.

infabo · Mon Feb 17, 2025 11:56 pm

I cant see much details on this low res screenshot, but: you seem to ping wifi-clients from AP. What is written in the log while timeout?

erlinden · Tue Feb 18, 2025 9:18 am

And yes, I have been through the hoops with support with rif's.

Could you give the netinstall hoop a try? Just to make sure that the device is clean from start?

mndtrp · Tue Feb 18, 2025 10:04 am

I cant see much details on this low res screenshot, but: you seem to ping wifi-clients from AP. What is written in the log while timeout?

This is the what is logged related to wireless
https://imgur.com/a/SK5qpJL
*EDIT: None of the devices listed in the logs are the Google Cast devices that "falls off the network". And they keep their DHCP lease time. Meaning they are not disconnecting from WIFI, but the connectivity is still dropped (packet loss).

The error happen less if certain devices (Google Cast enabled) are "dormant". I.e. not streaming content to them.
If I remove the devices (Google Cast enabled) from my wireless network, then there are no issues.

All of this information with tons of details has been provided to MK support and the ticket is still active. Though it's been quiet from MK support for the last 3+ weeks.

mndtrp · Tue Feb 18, 2025 10:04 am

And yes, I have been through the hoops with support with rif's.
Could you give the netinstall hoop a try? Just to make sure that the device is clean from start?

I have performed multiple netinstalls.And even tried with minimal "default" configuration. Still the same.

erlinden · Tue Feb 18, 2025 10:39 am

I have performed multiple netinstalls.And even tried with minimal "default" configuration. Still the same.

Would you be so kind to share your config if not done already?

infabo · Tue Feb 18, 2025 11:10 am

What means "Google Cast enabled devices"? What kind of devices are these? You mean this all happens while casting e.g. Youtube from Android phone to your Android TV?

mndtrp · Tue Feb 18, 2025 12:04 pm

What means "Google Cast enabled devices"? What kind of devices are these? You mean this all happens while casting e.g. Youtube from Android phone to your Android TV?

Using the following devices Google Nest Audio, Google Nest Mini, CCwGTV(4K), Harman Kardon Soundbar, Xiaomi MI Smart Speaker to stream content from Spotify, Netflix, MAX etc.

mndtrp · Tue Feb 18, 2025 12:09 pm

I have performed multiple netinstalls.And even tried with minimal "default" configuration. Still the same.
Would you be so kind to share your config if not done already?

Thank you for asking, but I don't think it will shed any new light to this issue sharing a bare minimum device "default" configuration.
That type of configuration should "just work". And it does with RoS 7.14.3 and older.

pfyod · Tue Feb 18, 2025 5:47 pm

@mndtrp: Have you tried explicitly disabling management-protection? It's "allowed" by default for WPA2 but can be set to "disabled". The only relevant thing about Chromecasts that I can find is linked to protected management frames. Has mikrotik support confirmed to you that they tested the issue with some Chromecast devices connected to wifi?

P.S. I have the same problem as you (lots of Chromecast devices, nothing never than 17.4.3 works) but no means to easily test different ROS versions.

MichalPospichal · Tue Feb 18, 2025 11:32 pm

In addition to what I wrote here: viewtopic.php?t=198736&start=300#p1121487

When testing only 2 devices connected at a given time (WiiM Mini and Moto Edge Fusion 30) I realized, that the issue does not manifest when both devices are on different radios, that is WiiM Mini is on 2GHz and Moto on 5GHz, then it is perfectly stable.
Moto gets frequent random SA Query timeouts ONLY when both devices are on the same radio, and does not matter if 2G or 5G.

Not sure what to make of it, but to me it seems it cannot be some WiFi setting causing it, if if is abosutely fine when the clients are separated on different radios (with exactly the same WiFi settings) and fighting each other when connected on the same radio.

Maybe someone else knows more how exactly this works in ROS, from my point of view this must be something on driver or even HW level.

mndtrp · Wed Feb 19, 2025 8:09 am

@mndtrp: Have you tried explicitly disabling management-protection? It's "allowed" by default for WPA2 but can be set to "disabled". The only relevant thing about Chromecasts that I can find is linked to protected management frames. Has mikrotik support confirmed to you that they tested the issue with some Chromecast devices connected to wifi?

P.S. I have the same problem as you (lots of Chromecast devices, nothing never than 17.4.3 works) but no means to easily test different ROS versions.

Yes, I tested explicitly disabling management-protection with RoS 7.17rc2 and supplied supout.rif's to the ongoing support ticket I have with Mikrotik.
There was no difference in behavior with or without management-protection.

Starting to lose hope. As I opened the ticket late 2024 with a lot of back and forth testing multiple settings that Mikrotik support recommended. But now it has been quiet from support. No updates from their side for weeks and there are no relevant fixes in the current 7.18beta-rc releases.

pfyod · Wed Feb 19, 2025 9:10 am

What about putting the Chromecast devices on a separate virtual SSID?

mndtrp · Wed Feb 19, 2025 9:22 am

What about putting the Chromecast devices on a separate virtual SSID?

I have tried that. In addition to separate master interfaces 2.4 and 5. Same behavior.

This is also known to MikroTik support.

vic3apex · Wed Feb 19, 2025 10:13 am

The same issue viewtopic.php?t=208199

litvcom · Wed Feb 26, 2025 8:59 pm

Has anyone tried stable 7.18 yet? Same behavior or fixed? Please share your result.

mndtrp · Wed Feb 26, 2025 9:22 pm

Has anyone tried stable 7.18 yet? Same behavior or fixed? Please share your result.

Same behavior. See the link in the post above yours.

codesnake · Mon Mar 03, 2025 6:38 pm

I have same issue on MikroTik hAP ax^3 with ROS 7.18 and Samsung Galaxy S24 Ultra. With ROS 7.14.3 it works fine.

alibloke · Mon Mar 03, 2025 9:02 pm

7.19beta2 appears to be worse for me

massinia · Mon Mar 03, 2025 9:12 pm

I have same issue on MikroTik hAP ax^3 with ROS 7.18 and Samsung Galaxy S24 Ultra. With ROS 7.14.3 it works fine.

I have the same router and smartphone, the wireless connection is very stable with 7.18.1!
Post your configuration…

itimo01 · Mon Mar 03, 2025 9:22 pm

7.19beta2 appears to be worse for me

I agree. And I didn't have any problems to begin with!
Roaming on 7.19beta2 seems to be broken for me. Including 2.4Ghz stability (I think?)

alibloke · Mon Mar 03, 2025 9:29 pm

Created a supout and attached it to SUP-181003.

codesnake · Tue Mar 04, 2025 12:40 pm

I have the same router and smartphone, the wireless connection is very stable with 7.18.1!
Post your configuration…

Here's my WiFi 5G configuration. Nothing extraordinary:

set [ find default-name=wifi1 ] channel.band=5ghz-ax .skip-dfs-channels=10min-cac .width=20/40/80mhz configuration.antenna-gain=5 .country=Ukraine .mode=ap .ssid=SnakeNet_5G disabled=no security.authentication-types=wpa2-psk,wpa3-psk

On 7.18 I get periodically "connection lost" messages. The issue is random, the phone can stay connected for several hours, or disconnect several times in one hour. As I said on 7.14.3 it works fine, no disconnections.

erlinden · Tue Mar 04, 2025 12:49 pm

Here's my WiFi 5G configuration. Nothing extraordinary:

What device are you using? Setting gain manually should only be used for devices where antenna can be detached.
Otherwise you should use TX Power and leave gain to default.

codesnake · Tue Mar 04, 2025 3:35 pm

Here's my WiFi 5G configuration. Nothing extraordinary:
What device are you using? Setting gain manually should only be used for devices where antenna can be detached.
Otherwise you should use TX Power and leave gain to default.

It's MikroTik hAP ax^3, currently with 7.14.3. I didn't enter antenna gain manually, it came from default config.

litvcom · Wed Mar 05, 2025 11:27 am

I have the same router and smartphone, the wireless connection is very stable with 7.18.1!
Post your configuration…
Here's my WiFi 5G configuration. Nothing extraordinary:
Code: Select all
set [ find default-name=wifi1 ] channel.band=5ghz-ax .skip-dfs-channels=10min-cac .width=20/40/80mhz configuration.antenna-gain=5 .country=Ukraine .mode=ap .ssid=SnakeNet_5G disabled=no security.authentication-types=wpa2-psk,wpa3-psk
On 7.18 I get periodically "connection lost" messages. The issue is random, the phone can stay connected for several hours, or disconnect several times in one hour. As I said on 7.14.3 it works fine, no disconnections.

I think you need to read what is DFS (Dynamic Frequency Selection) and after reading it you will come to the conclusion that when you live in Ukraine, you need to turn it off.

robmaltsystems · Wed Mar 05, 2025 11:45 am

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.

mkx · Wed Mar 05, 2025 11:07 pm

You're allowed to use DFS channels as long as the device carries out the CAC check.

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.

robmaltsystems · Thu Mar 06, 2025 2:43 pm

I have like a billion IT devices connected. But those are working fine, just my xiaomi phones have the issue.

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.

robmaltsystems · Thu Mar 06, 2025 2:57 pm

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:

https://www.reddit.com/r/XiaomiGlobal/c ... n_5g_wifi/

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.

neki · Thu Mar 06, 2025 5:14 pm

Did you try to disable scan throttling? It's enabled by default

jaclaz · Thu Mar 06, 2025 6:17 pm

Never mind, wrong post.

robmaltsystems · Thu Mar 06, 2025 8:30 pm

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.

robmaltsystems · Thu Mar 06, 2025 8:38 pm

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.

maigonis · Thu Mar 06, 2025 10:30 pm

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?

robmaltsystems · Sat Mar 08, 2025 1:03 pm

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.

itimo01 · Sat Mar 08, 2025 2:07 pm

@robmaltsystems

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.

maigonis · Wed Mar 12, 2025 9:57 pm

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.

Does your wifi country mach on AP and phone? It will cause MT chips to disconnect, also adding BSSID on temp ignore list.

madpierrot · Wed Apr 09, 2025 12:50 pm

A user should have been able to get support to reproduce the bug:

viewtopic.php?t=208199#p1137476

nmt1900 · Mon Apr 28, 2025 2:41 pm

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.

infabo · Tue May 06, 2025 6:44 pm

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.

seriquiti · Tue May 06, 2025 6:59 pm

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.

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.

robmaltsystems · Wed May 07, 2025 12:07 pm

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.

ToTheFull · Wed May 07, 2025 12:58 pm

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.
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.

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.

JonathanYoung2161 · Sun Jun 01, 2025 1:14 am

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: viewtopic.php?t=198736

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: viewtopic.php?t=198736
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.

robmaltsystems · Sun Jun 01, 2025 3:09 pm

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?

itimo01 · Sun Jun 01, 2025 3:17 pm

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?

I'm gonna guess this will be the same issue. These APs also use Qualcomm Chipsets.

https://www.reddit.com/r/Ubiquiti/comme ... t3_18i1mwb

https://community.ui.com/questions/U6-P ... a454f378e5

But from what I remember they never really acknowledged the issue

JonathanYoung2161 · Sun Jun 01, 2025 5:18 pm

@robmaltsystems If it's a Qualcomm driver issue, then MikroTik should **roll back to the working driver version** until a fix is available. They have the power to negotiate with Qualcomm as a manufacturer.

The real problem is MikroTik's **complete lack of acknowledgment** of this issue. It's unacceptable that paying customers had to reverse-engineer this problem and find our own workaround (staying on 7.14.3) while they remain silent.

MikroTik could easily revert to working drivers temporarily or at minimum communicate transparently about the issue. Instead, they're shipping broken firmware and forcing customers to downgrade just to get basic WiFi functionality.

infabo · Sun Jun 01, 2025 7:02 pm

I'm quite sure the driver wasn't updated without a reason. Most likely, it was to support new devices that only work with version 7.15 or later. If it were as simple as just reverting the change, MikroTik probably would have done that already.

maigonis · Mon Jun 02, 2025 12:37 pm

I'm quite sure the driver wasn't updated without a reason. Most likely, it was to support new devices that only work with version 7.15 or later. If it were as simple as just reverting the change, MikroTik probably would have done that already.

That is most likely the reason.

Mon Jun 02, 2025 12:47 pm

Regarding Chromecast devices, we do have news. Qualcomm firmware with fixes is being tested internally now.

kivimart · Mon Jun 02, 2025 1:03 pm

Regarding Chromecast devices, we do have news. Qualcomm firmware with fixes is being tested internally now.

Great news! I'm looking forward to this.

robmaltsystems · Mon Jun 02, 2025 2:09 pm

That's good news!

Fri Jun 06, 2025 1:43 pm

Also Intel issues seem to be fixed now with this new update. So hopefully next update will resolve most wifi issues, fingers crossed.

infabo · Fri Jun 06, 2025 2:07 pm

I hope so. These frequent disconnects ("MAC@wifi disconnected, too strong signal, signal strength 158") are one of the reasons why I cant use wap ax as a daily driver.

erlinden · Fri Jun 06, 2025 2:15 pm

I hope so. These frequent disconnects ("MAC@wifi disconnected, too strong signal, signal strength 158") are one of the reasons why I cant use wap ax as a daily driver.

In my experience the value of the signal strength is incorrect (signal should be less than -90dBm or something around). And is therefor a valid reason to disconnect. Why the conclusion that you can't use it?

Fri Jun 06, 2025 2:21 pm

It continues to strike me as odd there is such a difference in user experience.

I'm connected to my wAP AX (capsman managed) since 06h13 this morning. That's 7h already. Zero disconnects (and using Azure Virtual Desktop, I would know within the millisecond if the connection borks).
My laptop has Intel AX201 card (Wifi 6, 160Mhz).

infabo · Fri Jun 06, 2025 2:32 pm

I hope so. These frequent disconnects ("MAC@wifi disconnected, too strong signal, signal strength 158") are one of the reasons why I cant use wap ax as a daily driver.
In my experience the value of the signal strength is incorrect (signal should be less than -90dBm or something around). And is therefor a valid reason to disconnect. Why the conclusion that you can't use it?

I don't know what the actual signal is. It says 158. And when I look at the registration table for this client it says -83. So what? I reported this "too strong signal" very very months ago to support and some weeks ago I provided additional supout.rif and got response that Mikrotik is already working on a fix together with Qualcomm. So now we are here awaiting a new driver fixing a variety of different symptoms/issues.

ToTheFull · Fri Jun 06, 2025 4:09 pm

Also Intel issues seem to be fixed now with this new update. So hopefully next update will resolve most wifi issues, fingers crossed.

Why not just drop a link to 7.21_ab85 for those interested in testing. you will soon have an answer!

Fri Jun 06, 2025 4:24 pm

Caution, this is pre-release that most likely contains other bugs. I can't guarantee that with this version something will not burst into flames or something. https://mt.lv/nightly-build DO NOT INSTALL THIS if you use it for something important.

infabo · Fri Jun 06, 2025 4:39 pm

No thank you. I better wait for 7.19.2.

ToTheFull · Fri Jun 06, 2025 6:04 pm

Cheers Normis, now testing on Hap_AX2 and Cap_AX WiFi results are as expected.

====== RESULTS SUMMARY ======
Bufferbloat Grade,A+

====== RESULTS SUMMARY ======
Mean Unloaded Latency (ms),25.2
Increase In Mean Latency During Download Test (ms),2.52
Increase In Mean During Upload Test (ms),0

Download speed (Mbps),256.782
Upload speed (Mbps),25.749

====== LATENCY TEST DETAIL ======
Unloaded - Median Latency (ms),24.81
Unloaded - 95th %ile Latency (ms),33.5
Unloaded - Mean Latency (ms),25.2
During Download - Median Latency (ms),24.71
During Download - 95th %ile Latency (ms),49.83
During Download - Mean Latency (ms),27.73
During Upload - Median Latency (ms),22.98
During Upload - 95th %ile Latency (ms),34.57
During Upload - Mean Latency (ms),23.88

===== BUFFERBLOAT IMPACT ======
Web Browsing,PASS,PASS
Audio Calls,PASS,PASS
4K Video Streaming,PASS,PASS
Video Conferencing,PASS,PASS
Low Latency Gaming,PASS,FAIL

Ca6ko · Sat Jun 07, 2025 9:56 am

I better wait for 7.19.2

First comes 7.20 beta then 7.20 rc and
then we wait for the new driver in 7.20 stable

Sat Jun 07, 2025 10:06 am

It's on the wifi-qcom part which is a separate package so they can easily make it available in 7.19 chain.

infabo · Sat Jun 07, 2025 10:13 am

I better wait for 7.19.2
First comes 7.20 beta then 7.20 rc and
then we wait for the new driver in 7.20 stable

According to Normis already in 7.19.2: viewtopic.php?p=1146875#p1146875

infabo · Sat Jun 07, 2025 10:23 am

Cheers Normis, now testing on Hap_AX2 and Cap_AX WiFi results are as expected.

Did you have different bufferbloat test results with previous driver?

ToTheFull · Sat Jun 07, 2025 10:51 am

No, I was just showing people it is working as expected for me is all.
Everything so far I see connection wise on both devices running this A/B is explainable. I have 70 items in my logs of which 25 of those are me logging in to the router which is running as CAPsMAN. The main reason I am trying this is to see if my 1 device that wont connect to WiFi SSID's with FT enabled which still doesn't. Look at the device connected since installation @ -87 which by the way is a brand new device. Am I hopeful for people with problems ? yes very.

mndtrp · Sat Jun 07, 2025 11:04 am

Caution, this is pre-release that most likely contains other bugs. I can't guarantee that with this version something will not burst into flames or something. https://mt.lv/nightly-build DO NOT INSTALL THIS if you use it for something important.

Can you also share the other packages related to the nightly builds?
I use ZeroTier and would like to be able to completely test the nightly builds.

FYI: Already running the 7.21_ab85 build including ZeroTier which was shared by support with me.
This build is working quite well. No noticeable issues these past 3 days.

Thanks in advance.

kib0rg · Tue Jun 10, 2025 5:22 am

Caution, this is pre-release that most likely contains other bugs. I can't guarantee that with this version something will not burst into flames or something. https://mt.lv/nightly-build DO NOT INSTALL THIS if you use it for something important.

Can we have container package for 7.21 nightly please.

Tue Jun 10, 2025 8:53 am

Wait for the appropriate beta, perhaps ?

maigonis · Thu Jun 12, 2025 1:35 am

I did test new qcomm fw for 5days. My network is not suffering from "drop all the 5ghz band stations" issues, but individual stations/groups related disconnects. Firmware is still not perfect, might be my devices issue/configuration related, but I still see random deauth frames sent from AP to stations from time to time. Also reason code 3 connection drop between ROS devices is still there (wap ax to ax3, I have seen this issue mentioned by PTP/PTMP link users). Besides that there is improvements, some device whit stability issues are now holding connection. I did not specifically tested this, but looks like modulations are now holding better, maybe improvements to beam forming? (APs channels are fixed, also gain)

I did update my sup ticket whit more detailed report for MT team at SUP-174626.