2 APs - Windows Laptop won't roam or reconnect

[Stahab]

Had exactly the same problem with Windows wireless clients, especially with those having Intel WiFi NICs.
Both my APs are also hAP AX S.

Been able to solve this problem by configuring connect-priority=0/1 at /interface wifi security section of CAPsMAN configurations.

Been working fine since I made the above change (since routerOS v7.21) and still working fine using v7.23.3.

[vic666]

Thanks for letting us know about your experience.

Here is what the manual says on connect-priority.

connect-priority (accept-priority/hold-priority (integers))

These parameters determine, how a connection is handled if the MAC address of the client device is the same as that of another active connection to another AP.

• If (accept-priority of AP2) < (hold-priorityof AP1), a connection to AP2 wil cause the client to be dropped from AP1.
• If (accept-priorityof AP2) = (hold-priorityof AP1), a connection to AP2 will be allowed only if the MAC address can no longer be reached via AP1.
• If (accept-priorityof AP2) > (hold-priorityof AP1), a connection to AP2 will not be accepted.
• If omitted, hold-priority is the same as accept-priority.

By default, APs, which perform user authentication, have higher priority (lower integer value), than open APs.

So, if you set accept/hold priority to 0/1, is this not what the default would do anyway?

[Stahab]

The default should work as stated in the manual, but it doesn't in some cases. In my case default setting would work correctly for mobile phones and tablets, but would create exactly the same problem you described for Windows laptops, especially those with Intel WiFi cards. I had been pulling my hair for months, until I set the connect-priority=0/1 that solved this issue.
With default connect-priority=0/0 and in areas where both APs were in range, Windows clients would cycle between AP1 and AP2, up to a point that they would be completely rejected connection by above APs. I had to disable Windows' WiFi for a few times and try to reconnect, in order to finally get them to connect to AP. When moved from that area, the problem reoccured.

Probably a bug within routerOS / hAP AX S or a hAP AX S compatibility issue with Windows, that is mitigated by connect-priority=0/1. I remember that when I tested one hAP AX^2 combined with one hAP AX S, I didn't have this problem.

So if you don't wish yet to deploy V7.24RC2 before it becomes Stable, you can try if the above setting works for you and revert back to default setting when V7.24 Stable is released.

[vic666]

I guess that's one of the things that were improved / corrected in 7.24. Without detailed release notes, it's practically impossible to know for sure. More transparency on Mikrotik's part would be much appreciated.

Thanks a lot for your additional remarks, hopefully they will be of help to someone else.

[holvoetn]

@Stahab

connect-priority=0/1

That setting is already needed for quite some time ?
I just checked, I have it set on all my capsman setups for so long I almost didn't remember it.

Here is a thread from 2024 where it was already advised to use it.

FT between ax & ac

Is Fast Transition supposed to work between ac and ax networks? I have a mixed setup of 4 CAPs (2 hap ax2, 1 hap ac2, 1 wap ac) which I was able to configure with wifi-qcom and wifi-qcom-ac using an RB4011 as CAPSMAN and using manual bridge config on the ac devices to make VLANs work, however it seems that fast transition is not working between ac and ax, is that expected? I have a single security configuration profile which is used by both the ac and the ax configuration profiles but I do have …

[Stahab]

Looks like it has solved similar problems in the past. Using connect-priority=0/1 seems to help clients move from one radio to another more decisively when combined with roaming features, although this is not the primary documented purpose of the setting.