No default steering neighbour group with CAPsMAN

It’s also been months not hearing from you too.

It’s also been months not hearing from you too.

True, can’t comment anything when there’s nothing new to share…

I confirm, there is NO DYNAMIC entry when using CapsMan2.

It only affects profiles with EAP authentication.

MT support finally responded and confirmed that no steering group is automatically created if EAP is used as a authentication mechanism:

That being said, regarding the original query. Feedback from developers currently is as follows:

Dynamic neighbor groups are automatically created while using PSK, if the same SSID and PSK are used, these attributes tell us that interfaces have the same connection requirements, since we have this information, RouterOS can create a dynamic group for this scenario, for these specific interfaces.

In the case of EAP, currently, it’s not possible to create automatic neighbor groups, since there are no comparable attributes that would guarantee that the connection requirements are the same in all cases. Which, unfortunately, means that the network administrator needs to specify that interfaces are part of the same group.

We might investigate in the future, if we can find some workaround that would allow dynamic neighbor steering groups for EAP, but currently, I can’t give any guarantees regarding that.

I asked them to add some information to the documentation, which they did right away: https://help.mikrotik.com/docs/display/ROS/WiFi#WiFi-Steeringproperties

Which is great they added the line to the documentation. That’s what brought me here. What they forgot to add is HOW do you add a neighbor group manually? I’ve been looking for a way to do this, but there isn’t an ADD button and the CLI doesn’t have an ADD command under neighbor-groups.

You make a neighbour group in steering. Two locations (and from the GUI there is a tab steering:

/interface/wifi/configuration/steering
/interface/wifi/steering



 /interface/wifi/steering/neighbor-group> 
comment     edit     find     print     reset     set

There is no option yet, even in CLI, to create neighbor group.

thats the place you can print them. you define them one level up.

No, you can’t!? One level up you can define custom steering settings which can refer to an existing neighbor-group, but as far as I can tell there is no possibility to create your own custom neighbor-group.

of course you can.

Really ?

/interface/wifi/steering> add neighbor-group=test name=test

DONE.

Don’t confuse with dynamic neighbor-groups …

Can you actually display/print the neighbor-group (and its BSSIDs)? To me it appears that you just added a steering configuration with a reference to a non-existent neighbor-group.

Edit: My bad, it works as described! As soon as you assign the steering configuration to a wifi interface, the referenced neighbor-group is created automatically. I never tried this before, as I was expecting to see an empty neighbor-group before assignment.

Old thread, I know, but I don’t quite understand the neighbour groups. I have set up identical steering group and a neighbour group names on two Mikrotik devices but each device only has a BSSID relating to its own MAC address. Should I see both Mikrotik devices in each neighbour group list?

hAP ax^3

# 2025-03-14 19:01:36 by RouterOS 7.18.2
# software id = 1ZA1-H62T
#
# model = C53UiG+5HPaxD2HPaxD
# serial number = xxxx
/interface wifi steering
add 2g-probe-delay=yes disabled=no name=test neighbor-group=test rrm=yes wnm=yes
[xxxx@hapax3] /interface/wifi/steering> neighbor-group/print
 0 name="test" bssids=48:A9:8A:E5:6D:DC
[xxxx@hapax3] /interface/wifi/steering>
/interface wifi security
add authentication-types=wpa2-psk,wpa3-psk connect-priority=0/1 disable-pmkid=yes \
    disabled=no ft=yes ft-over-ds=yes group-key-update=55m management-protection=\
    allowed name=common-auth sae-anti-clogging-threshold=0 wps=disable

Audience:

# 2025-03-14 20:01:34 by RouterOS 7.18.2
# software id = BFXB-YGSQ
#
# model = RBD25G-5HPacQD2HPnD
# serial number = xxxx
/interface wifi steering
add 2g-probe-delay=yes disabled=no name=test neighbor-group=test rrm=yes wnm=yes
[xxxx@Audience] /interface/wifi/steering> neighbor-group/print
 0 name="test" bssids=74:4D:28:F4:F1:AA
[xxxx@Audience] /interface/wifi/steering>
/interface wifi security
add authentication-types=wpa2-psk,wpa3-psk connect-priority=0/1 disable-pmkid=yes \
    disabled=no ft=yes ft-over-ds=yes group-key-update=55m management-protection=\
    allowed name=common-auth sae-anti-clogging-threshold=0 wps=disable

Steering only works for radios, controlled by same entity. That can be two radios (on individual device with dual-band support) or many radios if controlled by CAPsMAN.

Ok got it - thanks. Depoyed CAPsMAN today and now see the BSSID’s in the Neighbour Group. However… the device I’m testing with, MacbookAir, is not fast switching between SSID’s. I am connected to an Audience (AC network) upstairs and when I go downstairs, right next to the hAP ax^3, it does not connect to that AP. If I turn off wifi and turn back on, only then does it connect to the ax^3.

[xxx@hapax3] /interface/wifi> export where [find disabled=no]
# 2025-03-15 11:30:59 by RouterOS 7.18.2
# software id = xxx
#
# model = C53UiG+5HPaxD2HPaxD
# serial number = xxx
/interface wifi channel
add band=2ghz-ax disabled=no frequency=2412,2437,2462 name=ch-24-ax reselect-interval=3m..4m skip-dfs-channels=all width=20mhz
add band=5ghz-ax disabled=no frequency=5745 name=ch-5-ax reselect-interval=3h..4h skip-dfs-channels=all width=20mhz
add band=5ghz-ac disabled=no frequency=5180 name=ch-5-ac reselect-interval=3h..4h skip-dfs-channels=all width=20mhz
add band=2ghz-n disabled=no frequency=2412,2437,2462 name=ch-24-ac reselect-interval=3m..4m skip-dfs-channels=all width=20mhz
/interface wifi security
add authentication-types=wpa2-psk,wpa3-psk connect-priority=0/1 disable-pmkid=yes disabled=no encryption=ccmp ft=yes ft-over-ds=yes group-encryption=ccmp \
    group-key-update=1h management-protection=allowed name=common-auth sae-anti-clogging-threshold=0 wps=disable
add authentication-types=wpa2-psk,wpa3-psk connect-priority=0/1 disable-pmkid=yes disabled=no ft=yes ft-over-ds=yes group-key-update=55m \
    management-protection=allowed name=IoT sae-anti-clogging-threshold=0
/interface wifi steering
add 2g-probe-delay=yes disabled=no name=steering_home neighbor-group=SAPLING rrm=yes wnm=yes
/interface wifi configuration
add beacon-interval=200ms channel=ch-5-ax country=Australia disabled=no dtim-period=1 mode=ap name=common-conf qos-classifier=priority security=common-auth \
    ssid=SAPLING steering=steering_home
add beacon-interval=200ms channel=ch-5-ac country=Australia disabled=no dtim-period=1 mode=ap name=cfg-5ac qos-classifier=priority security=common-auth ssid=\
    SAPLING steering=steering_home
add beacon-interval=200ms channel=ch-24-ax country=Australia disabled=no dtim-period=1 mode=ap name=cfg-24 qos-classifier=priority security=common-auth ssid=\
    SAPLING steering=steering_home
/interface wifi
# operated by CAP 74:4D:28:F4:F1:A7%bridge, traffic processing on CAP
add channel=ch-24-ac configuration=cfg-24 configuration.mode=ap disabled=no name=cap-wifi1 radio-mac=74:4D:28:F4:F1:A9 security=common-auth
# operated by CAP 74:4D:28:F4:F1:A7%bridge
add channel.frequency=5180 configuration=cfg-5ac configuration.mode=ap name=cap-wifi2 radio-mac=74:4D:28:F4:F1:AB
# operated by CAP 74:4D:28:F4:F1:A7%bridge, traffic processing on CAP
add channel=ch-5-ac configuration=cfg-5ac configuration.mode=ap disabled=no name=cap-wifi3 radio-mac=74:4D:28:F4:F1:AA security=common-auth
set [ find default-name=wifi1 ] comment="5GHZ AX" configuration=common-conf configuration.mode=ap disabled=no
set [ find default-name=wifi2 ] channel=ch-24-ax channel.frequency=2412,2437,2462 .width=20/40mhz comment="IoT 2GHZ AX" configuration=IoT configuration.mode=\
    ap .qos-classifier=priority disabled=no security=IoT security.authentication-types=wpa2-psk,wpa3-psk
/interface wifi capsman
set ca-certificate=auto certificate=auto enabled=yes interfaces=bridge package-path="" require-peer-certificate=no upgrade-policy=none
/interface wifi configuration
add beacon-interval=200ms channel=ch-24-ax country=Australia disabled=no dtim-period=1 mode=ap name=IoT security=*4 ssid="SAPLING IOT" steering=steering_home
/interface wifi provisioning
add action=create-enabled comment=5-AC disabled=no master-configuration=cfg-5ac supported-bands=5ghz-ac
add action=create-enabled comment=24 disabled=no master-configuration=cfg-24 supported-bands=2ghz-n

Wireless clients always decide on their own when to abandon old BSSID. The benefit of having proper roaming set up on infrastructure side is a) clients get a list of “good roaming candidates” so they can measure other BSSIDs faster - no need to read SSID names on all supported WiFi channels, just measure signal strength of certain AP MAC addresses on certain channels - and b) roaming procedures on infrastructure side are faster (traffic starts to flow over new BSSID sooner than without FT). So if wireless infrstructure supports roaming standards, client may decide to abandon old BSSID sooner … and after decission to do that it can find best target faster.

But if client thinks that old BSSID “is good enough”, then wireless network can’t force it to roam (except if wireless network disconnects the client and in this case client does full connect procedure … if it doesn’t take it personally and goes for a completely different SSID). And client behaviour is vastly different even if they all support same standards.

I have a network of 3 APs (running e.g. 5 BSSIDs), two are modern and controlled by CAPsMAN (4 BSSIDs with full roaming features) and one is old (running wireless driver). Even though SSID and PSK is the same, clients don’t like to switch to the old one … because BSSID is not on the roaming list. That AP is in the cellar, so some clients do connect to it from time to time … if they loose connection to all of BSSIDs in steering group (signal strength drops below -90dBm). Way back is bumpy as well.
Roaming between BSSIDs in the steering group is pretty smooth (a single short cracking sound while in VoWiFi call is all) … but AP coverages don’t overlap too much (they are in different floors, roaming area is on the staircase). Devices tend to roam at signal strength of around -75dBm in my use case.

Thanks. That makes sense. I think I have it working now and clients seem to be roaming without issue. I notice it when I have Inbox open and roam the connection doesn’t drop now.