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
which points you to this
https://help.mikrotik.com/docs/display/ ... iFiCAPsMAN
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: viewtopic.php?t=202578
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/ ... iFiCAPsMAN
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 ... fault.webp
You still have a network to set up.
Please, write a page dedicated to CAPsMAN v2.
Thank you
# Update
From the change log:
2. 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.
3. 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. 
# Update 9
This page explains the difference with "wireless" and "wifi-qcom".
viewtopic.php?t=202578
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.
