Provisioning not respecting name-format setting when provisioning local interfaces

RouterOS Wireless Networking
1

Capsman is running on cAP AX, newest 7.13.2 ROS.

When own/local radios are set to local provisioning, they get provisioned through the provisioning rules, however name-format setting is not applied. Radios are named wifi1 and wifi2 instead of for example: hostname-5G-wifi

here is the provisioning config:

/interface/wifi/provisioning/ print detail 
Flags: X - disabled 
 0   supported-bands=5ghz-a action=create-dynamic-enabled master-configuration=cfg1 name-format="%I-5G-wifi" 

 1   supported-bands=2ghz-n action=create-dynamic-enabled master-configuration=cfg1 name-format="%I-2G-wifi"

name-format works well with the remote CAPs.

Is this by design or is it some small bug?

2

Local radios have (default) names before provisioning even starts, so they don’t need (new) names on CAPsMAN device (unlike remote radios which don’t exist on CAPsMAN until they get provisioned).

And since local radios exist as soon as driver is loaded, you can rename them (simply set different name on interface under /interface/wifi).

3

Indeed. I was thinking about this. And setting local names to anything, after provisioning, they go back to wifi1 and wifi2 again. Of course I can go with create-enabled instead of create-dynamic-enabled, and then change the names easily, but I thought this might be something worth ‘fixing’.

4

I’ve documented my struggles here: http://forum.mikrotik.com/t/how-to-get-consistent-interface-naming-with-capsman3/172740/1

i’m also of the opinion that this is something worth fixing

A- Interfaces “wifi1” and “wifi2” keep their local names (but become dynamic, and loose their previous index on /bridge, suggesting they are deleted and re-created with the same name)
B- Slave interfaces local to the controller are created with “MikroTik” prefix on first boot, and “Identity” on second boot (using %I wildcard)
C- on remote CAPs, the zeroth interface (master) has no numeric suffix, but the slaves have, making reading difficult (slaves count from 2)

Some of these could probably be mitigated with more wildcards:
%band would be interesting (unifying the provision for multi-band setups, good for future-proofing)
%SSID or %VLAN would also be very useful


mostly, i’d like a consistent naming scheme so that i can follow a station on capsman/registration without loosing my mind

5

struggle with this “loosing from bridge” ate me 3 hours head banging and left me with 3 hours sleep less.

6

This would be more of a problem with configuration.mode=local OR capsman (where you want the “local” interfaces to belong to the bridge when capsman is offline)
when provisioning with mode=capsman, “capsman-only”, the proper way is defining the correct bridge in the datapath

it would be a lot clearer to all involved if the deleted-then-recreated interfaces followed Capsman naming conventions when caps-managed

7

You are right
You made a good suggestion

8

+1 from me and +300 from AP’s I manage

Also for counting interfaces, don’t leave first without any number, give it 0 (zero) or start with 1, or make an optional variable %NUMBER so if there is only one SSID per interface there won’t be any extra number, but if there are more allow us to make the names consistent.

9

Hi,

Or just, the config profile applied, as a “%” var for naming…
That hard to debug, cross info between capsman and few caps… ouch !

I don’t understand why, on capsman are named with provisionning naming patterns and this name is not used on caps. There no sense