The ABC of CAPsMAN v2 (with updates)

RouterOS Beginner Basics
1

Dear MikroTik support team,

Suppose you have just purchased new MikroTik hardware, and just finished updating it to version 7.13.3, with default packages and settings.

Suppose also that CAPsMAN is new to you.

You go to mikrotik.com, select “support” then “documentation” and look for an introduction to CAPsMAN.

The resulting page above shows no link to the topic.

Then you type “CAPsMAN” in the search window.

The search returns a long list of articles.

You select plain “CAPsMAN” because the other articles do not look like an introduction to the topic.

The “CAPsMAN” article dates back to 28/12/2023.

The article does not introduce CAPsMAN, however.

Its first section says “CAPsMAN AAA”: settings to configure CAPsMAN AAA functionality are found in the /caps-man aaa menu: […]

There are two problems with this.

The first is that you did not receive an introduction to CAPsMAN.

The second is that the menu “/caps-man” does not exist.

What do you do?

The official documentation is missing.

You go to the forum, select “Beginner Basics” and find this

http://forum.mikrotik.com/t/current-documentation-for-7-13-2-and-capsman/173101/1

which points you to this

https://help.mikrotik.com/docs/display/ROS/WiFi#WiFi-WiFiCAPsMAN

There are two problems with this, again.

The first is that you did not receive an introduction to CAPsMAN, again.

The second is that the menu “/interface wifi capsman” does not exist, again.

You keep reading around and find this:

https://help.mikrotik.com/docs/display/ROS/Wireless

It says:

  • routeros + wireless: Running both capsmans [new and old?] at the same time
  • routeros + wifi-qcom: New Capsman and own real interfaces

Then you look into your device, and learn that its only package is “routeros”.

Perhaps the device was sold without the necessary packages?

You go to mikrotik.com again, select “software”, and download the extra packages. The main package is “routeros” itself, already installed.

The extra packages contain wireless-7.13.3-arm64.npk and wifi-qcom-7.13.3-arm64.npk.

You look around and find no description of what they are.
Update: http://forum.mikrotik.com/t/7-13-wireless-package-split-question/172049/1

You upload wifi-qcom anyway, and reboot the device.

After reboot, /system/packages says you now have routeros + wifi-qcom.

Finally, you see the menu “/interface wifi capsman” in the terminal, which allows you to complete the “simple configuration example” in https://help.mikrotik.com/docs/display/ROS/WiFi#WiFi-WiFiCAPsMAN

The example terminates as follows:

“If the CAP is hAP ax2 or hAP ax3, it is strongly recommended to enable RSTP in the bridge configuration, on the CAP configuration.manager should only be set on the CAP device itself, don’t pass it to the CAP or configuration profile that you provision.”

"The interface that should act as CAP needs additional configuration under “interface/wifi/set wifiX configuration.manager=”

You understand that perhaps this is what you need to do:

/interface/bridge/set protocol-mode=rstp
/interface/wifi/set wifi1 configuration.manager=capsman
/interface/wifi/set wifi2 configuration.manager=capsman

You are still puzzled by the part “on the CAP configuration.manager should only be set on the CAP device itself, don’t pass it to the CAP or configuration profile that you provision”, because you need to configure the wireless devices in the CAPsMAN device itself. Indeed the wifi menu (GUI) says “no connection to CAPsMAN, managed locally”. So, you take a leap of faith, go to the wifi menu (GUI) select the first interface, then select CAP, then enter 127.0.0.1 in the CAPsMAN address. In the terminal, this corresponds to

/interface/wifi/cap set caps-man-addresses=127.0.0.1 discovery-interfaces=bridge enabled=yes

Now the interface is “managed by CAPsMAN”. At last!

Did it work?

No, it did not.

After reboot, the SSIDs in the “simple configuration example” do not appear in the list of available Access Points on air.

If you select the interface wifi1, then select “security”, the Security option is empty. The GUI says “managed by CAPsMAN”, however.

Also, in the list of interfaces, a new “cap-wifi3” 2ghz interface appeared, it is not managed by CAPsMAN, and has no security configuration…

You spent the whole day reading around, having to ignore CAPsMAN v1 instructions, to find yourself at this point.

The origin of this journey was the rather enticing Youtube video “MikroTips: managing many access points with CAPsMAN”, containing instructions that you still cannot follow, because it requires using the CAPsMAN menu in the GUI. There is no CAPsMAN menu in the GUI.

https://i.ytimg.com/vi_webp/taQ70m0DVYA/maxresdefault.webp

You still have a network to set up.

Please, write a page dedicated to CAPsMAN v2.

Thank you

# Update

From the change log:

  1. Drivers for older wireless and 60GHz interfaces, as well as the wireless management system CAPsMAN, are now part of a separate “wireless” package instead of being a part of the bundle package. This package can be uninstalled if not needed.

  2. The existing “wifiwave2” package has been divided into distinct packages: “wifi-qcom” and “wifi-qcom-ac”, and the necessary utilities for WiFi management are now included in the RouterOS bundle. RouterOS and “wifi-qcom-ac” packages alongside each other now fit into 16MB flash memory.

If you upload both packages (wireless and wifi-qcom), after reboot you find that “wireless” has been automatically disabled.

If you enable “wireless”, after reboot “wifi-qcom” is disabled.

The two packages exclude each other.

Using “wireless”, you see both menu /interface/wifi (CAPsMAN v2) and /interface/wireless (CAPsMAN v1) at the terminal, and you also see the CAPsMAN v1 menu at the GUI (subsection of Wireless).

The problem in having two wireless subsystems is that you need to manage both configurations, as they have defaults and triggers that may overrule your own settings.

Looking into the crystall ball, which of the two packages will eventually become obsolete? Will “wireless” die, and wifi-qcom become the new “wireless”? Is it worth having “wireless” now, and go through the pain of nulling /interface/wireless while also ignoring the /interfaces/CAPsMAN menu, because it will save you from removing the package wifi-qcom later on, as well as from installing wifi-qcom on current devices? Also, if it is true that “wireless” includes the new drivers and CAPsMAN v2, why having wifi-qcom at all?

# Update 2

I decided to keep the “wireless” package.

# Update 3

Since the CAPsMAN device cannot provision its own wireless interfaces, I decided to configure them locally.

# Update 4

I took a second device that was previously configured without CAPsMAN, then I booted it in CAPsMAN mode (15 seconds from cold boot with the reset button pressed).

The device is provisioned. Good news.

However, the old configuration is still present, as the old SSID appeared on air.

Manual reprovisioning did not clear the old configuration.
/interface/wifi/capsman/remote-cap/provision numbers=0

The login credentials are not provisioned. On first login, the device demands for a change of password.
This is annoying, as you were supposed to manage a large network of devices using a single CAPsMAN, and the task certainly includes keeping them secure.

Still on first login, the device shows a “RouterOS Default Configuration” message.

The following default configuration has been installed on your router:

CAP configuration

  • Wireless interfaces are set to be managed by CAPsMAN.
  • All ethernet interfaces and CAPsMAN managed interfaces are bridged.
  • DHCP client is set on bridge interface.
  • If printed on the sticker, “admin” user is protected by password.

Finally, the Quick Set menu, whose wireless configuration is empty.

So, why is the old SSID still showing on air?

Packages list shows routeros and wifi-qcom.

# Update 5

A new release is available: 7.13.4.
Let upgrade the CAPsMAN device and see what happens to the CAP…

After reboot, the CAP device shows the updated packages. Good news.
The package wifi-qcom is still there. I did not put it there. Should I leave it, or install “wireless”?

Was the firmware upgraded?
Yes, it was, but routerboard asks to reboot again to complete the task.
This is not expected, as the CAPsMAN should have rebooted the CAP a second time.

# Update 6

I deleted the cache bearing the old SSID, and a new default “MikroTik-9C1D50” SSID appeared.
The plan is to reset the CAP device (routerboot 5 seconds), then reboot again in CAPsMAN mode (15 seconds).
After the reset, the device disappeared from winbox. It is only visible if you first connect to its wifi.
Let see what happens if you go on and reboot it in CAPsMAN mode…
Happens that CAPsMAN catches the device. Good news.

This shows the CAP:
/interface/wifi/capsman/remote-cap/print detail

This shows the CAP’s interfaces as “cap-wifi”:
/interface/wifi/print

We wait for the provisioning to happen, and after a short while the SSID of the CAP shows up. Good news.

Moving on, the hard reset of the CAP had the effect of also re-opening a number of ports: ftp, telnet, http, etc. In the previous configuration I had only port 22 and port 443. The premiss with CAPsMAN was that you could manage a whole fleet from a single device. What I see here is that each CAP device still needs configuration, as you need to add users with their password, and need to configure the system. I was expecting CAPsMAN to provision in full, not just the wireless.

# Update 7

Nasty surprise. Security was not provisioned. I can connect to any SSID without password.

On CAPsMAN, where the “wireless” package is installed, the password is set in the security profile.
/interface/wifi/security/print detail

On CAP, where the “wifi-qcom” package is installed, there is no evidence of provisioning, exept for the red sign “managed by CAPsMAN” in the /interface/wifi menu.

# Update 8

It is clear that CAPsMAN is not managing the packages in the CAPs. It can upgrade CAPs, but it cannot manage their packages.

For consistency, to have the same packages on both CAPsMAN and CAPs, I enabled wifi-qcom on the CAPsMAN. The package “wireless” was automatically disabled.

When manual provisioning, the log on both the CAPsMAN and the CAP show no evidence that the action was performed. :frowning:

# Update 9

This page explains the difference with “wireless” and “wifi-qcom”.
http://forum.mikrotik.com/t/7-13-wireless-package-split-question/172049/1

This raises questions of business continuity.
Moving from /interface/wireless (“wireless”) to /interface/wifi (“wifi-qcom” and “wifi-qcom-ac”) may cause service interrruption.

If you have a mixed bag of devices, some 802.11ac other 802.11ax, then you need wifi-qcom on the CAPsMAN, wifi-qcom on the 802.11ax CAPs and wifi-qcom-ac on the 802.11ac CAPs. Since CAPsMAN does not manage packages in CAPs, you have to do it yourself.

Assuming your devices have “wireless” installed, what happens if you install “wifi-qcom”?
We already know that “wireless” will be automatically disabled.
Are the /interface/wireless settings automatically ported to /interface/wifi to prevent service interruption?

Users would have preferred to have everything in “wireless”.

# Update 10

We need to solve the problem with users logging without password.

Let us work on the CAPsMAN device with the wifi-qcom package. All other devices are powered off.

There are two entries for the wifi password:

  1. /interface/wifi/set security.passphrase=PASSWORD [find bound]
  2. /interface/wifi security add authentication-types=wpa3-psk,wpa2-psk name=sec1 passphrase=PASSWORD

The first entry corresponds to what you see in the Quick Set menu (GUI).
The second entry corresponds to what you see in the /WIFI/Security menu (GUI): it is a security profile.

In the original sequence above, following the “simple configuration example”, I created a security profile using this second entry. The example asked NOT to use CAPsMAN to provision the device’s own wireless interfaces. The instructions did not motivate the request. Using the Youtube video above, instructions were given to self-provision, I followed them, and they did not work. So, to clear the desk, I removed self-provision.

To recap., the CAPsMAN device now has a security profile, but no security setting for its own wireless devices.

Given the above, let us look into the configuration.

There is no CAPsMAN menu anymore, what you see in the WIFI (GUI) menu is a mixed bag of the old wireless GUI and the old CAPsMAN gui.
If you select “WIFI/Security”, you see the security profiles.
If you select, for example, wifi1 in the main WIFI page, then select Security, the first option you see is the selection of a security profile.
If you do not select a profile, you are supposed to enter the configuration.
However, if you do select a profile, the GUI is supposed to reflect the internal assignment of values to the variables set in the security profile.
By common sense, if you select a security profile, the first of the above two entries should be populated by the second.

That is, by common sense,

if you entered the password in the security profile [2],
2. /interface/wifi security add authentication-types=wpa3-psk,wpa2-psk name=sec1 passphrase=PASSWORD

and then selected sec1 as security profile for the local wireless device wifi1,

then it is reasonable to expect that the passphrase above [2] is automatically entered for wifi1 [1]

  1. /interface/wifi/set security.passphrase=PASSWORD wifi1

Experience shows that this mapping fails.

Yes, the local device is not self-provisioned, but nothing prevents you from assigning a security profile to the local wireless devices.

This is a programming error.

Another error is the hiding values from the user, at least from the standpoint of human-computer-interaction.
If a variable inherits a value, the GUI ought to say it.
If I select a security profile, for example, its values ought to be provisioned, and everywhere you go in the GUI you ought to see those inherited values.

The problem of user access on the CAPsMAN device was solved by setting the password manually:

  1. /interface/wifi/set security.passphrase=PASSWORD wifi1,wifi2

# Update 11

Provisioning of Security profiles fails on CAPs.

A fresh CAP, with default configuration (routerboot), booted in CAPsMAN mode (routerboot), is catched by the CAPsMAN, receives the configuration, shows the SSID on air, but users can login without password. To make sure I picked the CAP’s SSID, I cleared the cache of the pc and hid the SSID of the CAPsMAN’s own wireless devices, so those on air are the new ones from the CAP.

This result is disappointing and makes CAPsMAN useless.

This holds for routeros with wifi-qcom version 7.13.4.

1 Like
2

Maybe this? https://help.mikrotik.com/docs/display/ROS/WiFi


Nevermind: it seems you may have thst link already.

3

There is actually one link higher in the menu - search WIFI…which talks a bit about the packages → https://help.mikrotik.com/docs/display/ROS/Wireless
…
packages.jpg
…

The link is good, the germane bit is at COMPATIBILITY ( but as a new buyer, user, forum person, how the heck should he know all the history and know what to do, he has a point!! )

..
wifi2.jpg

1 Like
4

Already accounted for.

5

Setting up wifi is what seems a mess to me.
One should be able to set up ( basically working from right to left in the menus )
a. security settings
b. channels
c. configuration → assign channels to security settings
d. WIFI → assign wlans to configuration. DONE!!

Unfortunately, in configuration one can modify security settings, whereas they should be hard coded and fixed according to security settings
Unfortunately, in configuration, one can modify channel settings, whereas they should be hard coded and fixed according to channel settings.
The only tabs that should require any work is FT & EAP as those are UNIQUE to configuration, even internetworking, AAA, datapath, steering should be set in other menus not in configuration.
Unfortunately there are default settings in WIFI, that do not get filled properly by previous entries that show up as blank entries but are there nonetheless, and one has to do them manually regardless of what was assigned in configuration, channel or security.
The only thing one should be selecting in WIFI ( besides which wlan to which configuration) are DIFFERENT items then selected in (configuration, channel, security), which is ONLY status and traffic!!!

It is very confusing and illogical at least so far. Maybe there is some method to the madness.

6

Wifi follows an approach based on templates - profiles.
You can read about profiles and their priorities here: https://help.mikrotik.com/docs/display/ROS/WiFi#WiFi-Configurationprofiles
The steps (a.b.c.d) outlined work perfectly fine.
Configuration is not illogical, it just gives you more flexibility on how you can configure the device.
Roughly there are a few ways to go about it:

  1. configure the interface directly
  2. create a configuration profile, configure everything there, and assign it to the interface
  3. create individual security/channel/datapath templates, etc., and assign them to the configuration profile, which you later set on the interface
  4. use a mix of the mentioned steps, for what takes priority, take a look at the previously shared link.
  5. use Wifi CAPsMAN to provision a configuration profile to remote CAPs.
    In general, it is fine to just configure everything directly on the interface, configuration profiles can help ease the configuration if it is more complex, you want to change it in the future, or if you are running CAPsMAN with multiple APs.
    In general, if it seems confusing, it’s important to remember that all these approaches are optional, it is perfectly fine to use a single configuration profile, or to configure interfaces directly. It was made this way to alleviate configuration work, so the best approach is the one that fits your use case.

In the case of OP, if he had to install wifi-qcom package on hAP ax2, something went wrong with the upgrade process. We will add a note to the mentioned video, that it is not relevant for Wifi package.
I hear the points about CAPsMAN vs AP Controller (CAPsMAN) pages, we will look into merging them to avoid confusion.

As for Wifi CAPsMAN, the whole wifi package uses the same structure, it is not a separate menu as in the case of “/interface/wireless” and “/caps-man/”, hence it doesn’t have a separate page for it at this time.
If you have any other specific feedback, or examples, regarding documentation, please let me know here.

Expanding on “there are default settings in WIFI, that do not get filled properly by previous entries that show up as blank entries but are there nonetheless, and one has to do them manually regardless of what was assigned in configuration, channel or security.” - blank settings under interface are for the scenario where you override configuration profile settings for that specific interface, there is no “has to do them manually”, it is entirely optional.

7

Thanks for the explanation Guntis, but its the excessive choice :wink:, that had me put the ax3 on the shelf for months as I didnt understand what process to use.

If what one enters in security, then channel, and then goes to configuration and selects a channel name and security name, ALL of the already chosen sub-parameters must be applied in applicable configuration tabs. If one then enters the WIFI menu and selects a configuration ALL of the sub-parameters of security, channel and configuration must populate all the applicable WIFI section.

If this was the case I would agree with you, it is not the case and there in lies the lack of logic.
I appreciate I could have ignored the channel, security and config main tabs, that is indeed great flexibility, IF the other method was also viable.

The truth is, one still has to go into WIFI and over write default WIFI settings and entries that are NOT APPLIED, even after selecting all security parameters, all channel parameters, and then selecting security name and channel name in configuration and the in wifi selecting configuration name for a WLAN.

In other words, working from right to left is INCOMPLETE (not fully applied) and thus the ONLY viable method is entering everything in WIFI and ignoring the other tabs.

(ps talking a simple non-capsman setup)

8

Problem here is that even when you use this method, you still need to go over all tabs to empty the default settings before all those nice profiles are fully used.
There should be a button “clean wifi settings” and then you can start configuring.

9

Bingo, therein lies the problem GUNTIS, hidden fact that the ordinary user is not going to know, nor I with some experience knew, but Sir Holvoetn, seems to be aware of and he is far from a novice wifi user [ I think he sleeps with antennas in orifices. :slight_smile: ]

Due to the above issue, as stated, I shelved the unit for quite awhile as being unprogrammable.

10

Truth to be told, I use a shortcut: reset to caps mode.

Everything cleared and only one setting to be changed then, capsman related (since most of APs I use are in full bridge mode anyhow so saves me that part as well).
And then I can start.

11

Currently, it seems like a misunderstanding, which we will try to further clarify in the documentation.
“If what one enters in security, then channel, and then goes to configuration and selects a channel name and security name, ALL of the already chosen sub-parameters must be applied in applicable configuration tabs. If one then enters the WIFI menu and selects a configuration ALL of the sub-parameters of security, channel, and configuration must populate all the applicable WIFI section.” - the core principle in Wifi configuration, while using profiles, is inheritance and if you go up one “parent” level, there will be blank settings, but that does not mean they are not loaded, those are there to give you the option to override the ones you load from profile. For example, if you create:

  1. “/interface wifi channel add band=5ghz-ac disabled=no frequency=5180 name=channel1 width=20mhz” <<< you will see frequency, width, and band filled here.
  2. “/interface wifi configuration add channel=channel1 country=Latvia disabled=no name=cfg1 ssid=ConfigSSID” <<< configuration profile will show that it uses channel1, blank entries in channel tab are only for overriding the properties that would be inherited from channel1
  3. In GUI under interface after setting the “configuration=cfg1”, you will see the inherited entries, in CLI you can see them with “/interface/wifi/actual-configuration/print”, which you can override directly on interface, if needed.
    I can see how in step 2, under a specific sub-profile tab, it might seem misleading that there are blank entries, but it is optional to do anything there, by default everything from sub-profile (channel1 in the example) will be inherited.
    We will adjust the documentation for configuration profiles to make it clearer - regarding “blank” fields under sub-profile, thank you for bringing this to our attention. Perhaps we can make it show what properties are inherited from the sub-profile in the main configuration profile, like they do under “/interface/wifi/”, but I can’t guarantee that, we need to look into it.

Regarding the point of having to unset the configuration on “/interface/wifi” if the default configuration is used, yes, that’s true, though unlikely that we will change it as while it would provide some ease of use if you are using configuration profiles, a similar case can be made that losing the ability to override configuration on a per-interface basis would be bigger loss. On top of that primary motivation of configuration profiles is for multiple AP scenarios - CAPsMAN.

Regarding the mentioned CAPs mode workaround, another option is to use “/interface/wifi reset wifi1,wifi2”, it will clear the configuration from the interfaces. Another workaround would be to create a provisioning rule, that matches local Wifi interfaces, and then going to the radio tab and provision it with it. Though I wouldn’t recommend it, as it seems to be more work than other methods, if you do decide to do that, create-enabled, in provisioning rule might be a better approach, as then you retain some control over the interface. If “create-dynamic-enabled” is used, you would have to disable that specific provisioning rule and reprovision the interface from “/interface/wifi/radio” menu to regain control of it.

Thank you for the feedback. We will take it into consideration.

12

Thanks for your responses, Guntis.
Much appreciated.

Dang ! Didn’t think of that before, good to know.

13

First things first…

One appreciates the existence of alternative paths, but there must by ONE easy path for the beginners.

The problem here is how to go from point A to point B without getting lost with outdated documentation while dealing with a device that seems to have a mind of its own.

14

Understood Guntis, and also much thanks for taking the time on this one… its important!

I believe a better approach would be to REMOVE blank entries and put in the values entered into the previous Tabs of security, channel, then configuration, and then in WIFI, WHEN THE configuration is assigned, accepted ( this action, removes default entries blanks etc.).
By making sure all the sub parameter entries have a WHITE background, not greyed out, it should be clear to the admin that:
a. the correct entries are in place (based on parameters already entered
b. the entries CAN BE MODIFIED ( state so in documentation )
I may be mistaken but the blank entries, of which you speak, are currently grey, which makes them appear not enterable?? In any case they should contain the correct values and have a white background if assigned by configuration name..

Alternatively, what I would do is auto-populate the entries as I’ve stated, right to left, no blanks etc…
Then when you reach the WIFI main tab, and you assign configuration to WLAN, all entries are populated.
This time, they are displayed as in the option above EXCEPT, visible but GREYED OUT, in other words not modifiable, except any parameters not yet filled in. Be it FT, or something else.
BUT
What I do is give the option to the user to modify directly the WLAN, in the WIFI menu, as you wish to keep that flexibility.
…
modify.jpg

15

I hope you are reading the updates, and gathering answers. There is a gold mine of problems to be solved, and I am not here to waste time.

16

Yeah the “blank fields” showing the inherited value would go a long way to making this easier, I think. At least, it change the question to “where did this come from?” than trying to deduce the value being used.

17

Update 11 closes my comments here. I spent enough time on this, and had no help from Mikrotik or other users, so my conclusion is that CAPsMAN v2 is not production ready. Perhaps CAPsMAN v1 is production ready, but is being deprecated so I will not waste time on it.

18

Wrong conclusion.

Reboot due to upgrade to 7.13.3
It was running almost 80 days before.
2024-02-08_21-04-37.png

19

But we know you are a wizard and have a magic wand. :slight_smile:
Point being is it works if setup correctly. What we are trying to do is setup a process that works and less prone to error.
So do you have any other observations on a process to setup capsman so its simple, easy to understand and less prone to failure (robust).

The goal is to help the OP and all the others that follow.
How can you guide GUNTIS, into improving
a. the documtenation
b. the presentation of the options and how they are entered ( same as we have done above but for capsman entries ).

If you need incentive, I pray for your book on the subject everynight…

20

I am happy for you.