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

viewtopic.php?t=203791&sid=e0074289a92c ... 875ff3c851

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.

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


Nevermind: it seems you may have thst link already.

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
... .....

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!! )

..

Already accounted for.

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

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.

Wifi follows an approach based on templates - profiles.
You can read about profiles and their priorities here: https://help.mikrotik.com/docs/display/ ... onprofiles
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.

Thanks for the explanation Guntis, but its the excessive choice , 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)

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. ]

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

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.

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.

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.
......

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.

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.

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.

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.

But we know you are a wizard and have a magic wand.
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.............

Wrong conclusion.

Reboot due to upgrade to 7.13.3
It was running almost 80 days before.

I am happy for you.

Holvoetn, are there any missing or unreported or gotachas, like the default fields just filling in the WIFI entries, in the capsmanv2 entry method................

# Update 12

I was about to delete all CAPsMAN settings and provision the CAPs manually, then I tried this...

When writing security profiles to be provisioned, each profile has a security name, authentication types and a passphrase.

When writing configuration profiles to be provisioned, each profile has a section where you select the security profile. This is where the problem occurs. The selection of the security profile does not fill-in the form: the authentication types and passphrase are not filled in automatically.

When the CAP is powered off, in the WIFI/Security menu there are only three devices: wifi1, wifi2 and cap-wifi3.
The first two are managed locally.
The third one, cap-wifi3, comes alive when a CAP joins the manager, and its security section is not filled in automatically. The only pre-compiled value is the passphrase. The authentication types are blank.

On the CAP itself, after provisioning, the security section is not filled in.

What I did is to follow the trail and fill in manually in the CAPsMAN sections. I filled in the security profile in each configuration profile, repeating authentication types and passphrase. Then in the main WIFI menu, I selected cap-wifi3, and its security profile. The passphrase was pre-filled in, but the authentication types were blank. Then I entered the authentication types manually.

When the CAP joined in, two new interfaces appeared: cap-wifi1 and cap-wifi2. Their details cannot be filled in.

The result of this is, that the CAP now demands a password.

This proves that there is a programming error, as the values of profiles is not inherited. Once all profiles are filled in, then the CAP is provisioned with a working security profile.

Can you post the config which does not work please ?
I am not following what you mean.

Even if OP is giving up, still be good as few folk are following along now.

Personally I'd also collect a supout.rif from the main router & 1-3 of caps and email Mikrotik at support@mikrotik . @Guntis knows his stuff and been following along. If it's a bug, they'd need the supout.rif (or at least speed things along).

Whether something is bug or config – is really hard to know. At some point, bad usability is a bug.

When writing configuration profiles to be provisioned, each profile has a section where you select the security profile. This is where the problem occurs. The selection of the security profile does not fill-in the form: the authentication types and passphrase are not filled in automatically.

Why should this happen? You create a configuration template and select the security template you created before. The end. Working.

You can still enter a passphrase in configuration directly. Either to override the security template's passphrase or when you did not use a security template at all. You enter the passphrase/authtype directly on the configuration template.

Whether something is bug or config – is really hard to know. At some point, bad usability is a bug.

+1

When writing configuration profiles to be provisioned, each profile has a section where you select the security profile. This is where the problem occurs. The selection of the security profile does not fill-in the form: the authentication types and passphrase are not filled in automatically.

Why should this happen? You create a configuration template and select the security template you created before. The end. Working.

This.

It's important to note that profiles in new wifi configuration (channel, datapath, security, ...) are profiles, not templates. So when one selects a profile in a particular setup, the settings in profile are used directly, they are not copied over. And if later profiles are changed, the changes are applied to all settings / interfaces using those profles ... unlike with templates, where changes would not be propagated to already configured (and provisioned) interfaces.

IMO the only misleading thing is possibility to override profile settings inside a particular setup ...

Of course they are profiles and not templates.

And IMHO the possibility to override settings from an inherited profile is neat in some cases.

I don't know where it is in Winbox, but on CLI you can view the actual/effective configuration via /interface/wifi/actual-configuration/print.

In HTML webforms we know and are used to placeholders in input fields. Winbox should really make use of this! OP would have seen the inherited values as placeholder in the corresponding fields. As well the "origin profile" could be shown as well. This would help in visual troubleshooting in Winbox.

Whether something is bug or config – is really hard to know. At some point, bad usability is a bug.

+1

No, this is never the case by definition of a bug. Bad UX is a pita but surely not a bug.

We are following this topic and are taking notes on both how to improve the GUI in the next generation winbox, and the manual as well

We tried it with wiki and it ended in disaster, there were lots of errors in manuals and even some self promotion. This was even during period when only approved consultants could edit the wiki.

"When writing configuration profiles to be provisioned, each profile has a section where you select the security profile. This is where the problem occurs. The selection of the security profile does not fill-in the form: the authentication types and passphrase are not filled in automatically.
...
This proves that there is a programming error, as the values of profiles is not inherited. Once all profiles are filled in, then the CAP is provisioned with a working security profile."

I think that my post in this topic - post #11 likely addresses this (misunderstanding), if the scenario is as follows, and you are trying to provision this configuration to remote cap:
1) you made security profile
2) referenced it under "/interface/wifi/configuration/"
And then saw blank fields, which can seem as if security profile was not loaded by configuration profile, but it is not the case the sub-profile (security profile's values) are loaded into it, it just happens in "background" and is not displayed on the configuration profile itself. It would be displayed on "/interface/wifi" interfaces - on CAPsMAN or AP itself if it is not a CAP.
"On the CAP itself, after provisioning, the security section is not filled in." - configuration needs to be checked on device that controls interfaces, if CAPsMAN controls CAP, then it needs to be checked on CAPsMAN, not on CAP itself.
The blank values in configuration profile while sub-profile is loaded, are just an option to overwrite a value. Values can be overwritten in /interface/wifi/ as well, but /interface/wifi is "smarter" and shows what values were inherited from "/interface/wifi/configuration", including any that come from sub-profile that is assigned to the /interface/wifi/profile that was "set" or "provisioned" to interface.

As a side note, we are looking into the possibility of showing the inherited values in configuraiton profile as well, though I can't give any guarantees regarding implementation yet.

To be clear, I'm not trying to dismiss your experience, just trying to make sure if there is no misunderstanding here, and in case of misunderstandings, this thread is indeed quite valuable as we can see where to improve documentation or possibly RouterOS. Thank you.

If the case I quoted can't be explained by what I just wrote, please share the commands you used, where inheritance of sub-profile properties did not work, I have tried various approaches, but have not been able to repeat such scenario - in the sense that in what I see is - yes "blanks" will be shown in configuration profile that is true, but actual values can be seen on interfaces and in behavior of wireless.

Someone could start a community driven wiki. This forum isn't the right place for e.g. anav's long knowledge articles. Or other VLAN articles. It is hard to maintain and not easy to consume/read.

Some users have already done this. Neither uses a cloud-based solution however & both below could run as a /container theoretically
@tangent uses fossil SCM's built in wiki: https://tangentsoft.com/mikrotik/home
@eworm uses git-based web server: https://git.eworm.de/cgit/routeros-scripts/about/

But @Normis is right: a Mikrotik-run "wiki" was not a great way either. It was a mess.

Personally, I think this thread just shows the need for better formal docs. The OP has a router and dozen AP & clearly generally familar with networking, but not Mikrotik. There isn't some "Admin Guide" to deploying capsman2. The help.mikrotik.com does keep improving, but it's still a reference manual by command. Some high level overview: "How to setup a router with multiple APs to a controller" is totally missing & OP tried to follow section-by-section in help to figure this out, yet failed.

And IMHO the possibility to override settings from an inherited profile is neat in some cases.

I'm not saying it's not neat, I agree with that. I'm saying that it's misleading (or confusing) as witnessed by @OP's experience.

The approach for parameter entry has to be consistent and somewhat intuitive and logical. Really good documentation might help circumvent a less then exemplary UI/MMI but that might be too long winded for current Document practices.

https://createnewwiki.fandom.com/wiki/S ... ateNewWiki

You are making fun of the situation and of me (no pity pls). Improving docs is not something that you should make fun of.

You be tripping dude, you suggested a WIKI, and Normis provided you a viable link to starting one??? There was nothing more imparted.

In case you didn't notice, they are actually CONTINUALLY working on the MT documtenation and its indeed getting better and better all the time. ( just wish they would get rid of the extra firewall bloat that the router has no business attempting )
The fact that he and guntis are in this thread, and participating is a very positive indication.

https://createnewwiki.fandom.com/wiki/S ... ateNewWiki

You are making fun of the situation and of me (no pity pls). Improving docs is not something that you should make fun of.

I think you have misunderstood. I believe Normis was being earnest in his response. I DO think he makes it clear that Mikrotik isn't going to be hosting the wiki per his earlier posting as well. So if it's something you want - go for it. Either way, take a chill pill.

Dear MikroTik support team,

Only just come to this post and it made me smile but also grimace because this, in a nutshell, is why Mikrotik will always struggle in the SOHO market. Maybe they don't want to be part of this market. We've chatted about the relative easy of use of the Unifi cloud controller elsewhere but this is post is exactly why CAPsMAN really should be the domain of the networking professional. Not unlike Cisco I guess.

I realise that we're right in the middle of the confusing transition from legacy to new Wi-Fi drivers but I've spent hours on this, and I'm still a bit confused. Nothing new there!

There was another post about the dead Mikrotik controller, the idea of which I assume was to operate much like the Unifi controller which can be both on-premises or cloud based. Many of the higher power routers could run a small web server for cloud access. But it would have to be proxied via a Mikrotik host so put port forward/security issues to one side.

I ended up because I'm spending my own time today learning about CAPsMAN v2 on a legacy cAP ac environment. It's fun in a perverse way but doing it out of hours in case I break the client. They're only around the corner so I can pop around if I really cockup.

One of the biggest flaws of capsman design is: the caps manager does only provision wifi. As far as I am aware of. You put a brand new CAP device in caps-mode and it gets adopted. Done. The device is left alone with the default admin user without password - as most of the devices out there are without factory default password. Winbox, Webfig, and so on - all by default enabled.

I tend to change the identifier so always hit the password change option on first logon. But yes, would be good to impose a password change across an entire estate.

https://youtu.be/taQ70m0DVYA?si=ZiQ-RuPKNARN_r2L&t=1060

"Put into caps mode and that's it"

Nope. That's not it.

I tend to change the identifier so always hit the password change option on first logon. But yes, would be good to impose a password change across an entire estate.

The password-change "nag-screen" exists only for maybe 2 years. Before you weren't even asked to change it. And in Winbox you can skip it as well - by just closing the dialog. LOL