Capsman - provisioning of local interfaces

I am a little puzzled by the way local wifi interfaces are treated with CapsMan in ROS7

With CapsMan in ROS6 I used localhost 127.0.0.1 for referring to Capsman controller on same RB, and local interfaces were treated just like remote.

In ROS7 I find the combination of settings a little confusing.
In fact, when using a dedicated Capsman controller it is mainly plain sailing, each cap connects and gets provisioned as expected.

However for local interfaces it is not that straightforward.
In Configuration there is a setting Manager, which can be either “capsman”, “capsman or local” or “local”, but I struggle to see how this plays in combination with the “Cap” setting on the Wifi tab?

The documentation at https://help.mikrotik.com/docs/spaces/ROS/pages/224559120/WiFi reads

CAPsMAN cannot manage it’s own wifi interfaces using configuration.manager=capsman, it is enough to just set the same configuration profile on local interfaces manually as you would with provisioning rules, and the end result will be the same as if they were CAPs. That being said, it is also possible to provision local interfaces via /interface/wifi/radio menu, it should be noted that to regain control of local interfaces after provisioning, you will need to disable the matching provisioning rules and press “provision” again, which will return local interfaces to an unconfigured state.

I have tried this - manual provisioning of local interfaces, - and it actually works.
Then they appear in the interface list with names set by the provisioning rules and not “wifi1” and “wifi2”, just like remote interfaces.
I find the radio’s ability to pick a non-colliding frequency to be rather poor - often the caps in adjacent rooms end up on the same channel :open_mouth: , therefore I often resort to provisioning via Identity RegExp to separate them frequency-wise.

The “problem” is the need to do something manually upon deployment.
I want to maintain a standard set of config scripts (like I always did), paste them into the routers (caps) and just change the Identity (which includes the desired frequencies)
Similarly I only want to change Identity, SSID and encryption of the Capsman Controller device.

Then, myself or some other technician should be able to install and power up the equipment, and I expect it to work right away - like it did in ROS6 Capsman.

So I find it a little awkward to have to do things manually for the local interfaces. Things should be repetetive, i.e. applying a config script at any given time should give exactly the same result for the same hardware/ROS version without any manual interaction.

Shouldn’t it rather be possible to refer the Capsman Controller on own router (localhost) and thus treat local interfaces just the same way as remote ones?
IMHO the more uniform different entities are treated, the easier management becomes.

And where is the information about the manually provisioned interfaces stored?
If I keep a backup of the config and paste it into a new router, it’ll be gone I guess, and I will have to start over again with manual provisioning?
What I want is to connect power and network, wait for 1 minute and there we go.

CAPsMAN is indeed intended as central management. If your only problem is frequencies, you could either make a configuration per radio (with a fixed frequency) or start using releselect-interval. The latter will (background) scan if the frequency is the best choice:

https://help.mikrotik.com/docs/spaces/ROS/pages/224559120/WiFi#WiFi-Configurationprofiles
https://help.mikrotik.com/docs/spaces/ROS/pages/224559120/WiFi#WiFi-Channelproperties

This way, only identity is necessary during configuration of the CAP.

Yes I know, and what I intend to achieve is exactly that.

If your only problem is frequencies, you could either make a configuration per radio (with a fixed frequency) or start using releselect-interval. The latter will (background) scan if the frequency is the best choice:

WiFi - RouterOS - MikroTik Documentation
WiFi - RouterOS - MikroTik Documentation

In fact I was not aware of this setting, thank you! :slight_smile:

I am trying it now in a 3-story house with a cap in each story , and it appears as the caps are "playing games" with eachother, moving around among the frequencies all the time.
So it does not look like this algorithm is particularily smart.
Maybe I should provision story 2 to the desired channel (using RegExp) and leave 1 and 2 mending themselves?

Apart from this, Capsman Controller with local interfaces still is a pain to me.

If I specify a configuration statically for the ints, it works somehow.
wifi1 and wifi2 must then be statically specified in /int bridge port

If I use the same regime as for the connected caps, and provisions using the Provision button on the Radios tab, the interfaces are set up like I want them. Then they get a name like specified in name-format, and they are dynamically added to the bridge.
(if wifi1 and wifi2 were statically added to bridge, they then change to "unknown" in /int bridge port)

But it does not look like traffic is forwarded to/from local interfaces this way.
Clients authenticates and appears to be connected, however "no internet connection" appears.
Pinging gateway is not possible.
Any idea why

And I still can not get my head around how the different params relate to each other.
When does for instance "/interface wifi configuration manager" come to play, and how is it related to "/interface wifi cap"?

Mechanisms available that I have been trying is:
-Static specification of Configuration for each interface
-Setting "/interface wifi cap"
-"/interface wifi configuration manager"
-Manually provisioning using the "Provision" button

Which of the latter 3 are dependent of each other, and which are mutually exclusive?

Sorry for my ignorance, but what I want is a uniform and repetetitive way of configuring the controller - with or without local interfaces - and the caps.

Can you please share your current config of the CAPsMAN?

/export file=anynameyoulike

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

Afraid that in my desperation I threw away that particular cfg when factory-resetting and moving to a dedicated controller, but I'll try to re-create the problem.
Thank you so far!