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/R ... 59120/WiFi reads
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![:shock:]( "Shocked")
, 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.
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/R ... 59120/WiFi reads
I have tried this - manual provisioning of local interfaces, - and it actually works.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.
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
, 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.
Statistics: Posted by Bomber67 — Fri Mar 28, 2025 9:13 am