The ABC of CAPsMAN v2 (with updates)

Thank you :laughing:

In all seriousness:
I fully admit I am not an average user. But far from an expert nor magician either. There are others here having a LOT more knowledge then I do.

While the documentation can be improved (and yes, it can be improved quite a bit) all basic building blocks are there to learn how to tie all ends together.
Current documentation is using CLI commands but does it really have to be with screenshots from Winbox to make it more clear ?
Personally I don’t think so. At least it would not bring added value for most.

The basic setup from Help pages is a good starting point (maybe a bit too simplistic to my liking but ok).
What other examples or explanations are needed to put more meat to the bone ?

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

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.

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.

+1

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.

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

Normis,
wild idea …

Would it be helpful if selected users can participate in creating help contents and manuals ?

It would help to define the scenarios to be followed, define which format to use and then it’s fleshing out all the steps and instructions.
Obviously redacting authority would remain with MT staff.
I’m certain vast amount of existing users but certainly new users would be tremendously helped if better manuals are available.
And that can only be good for sales, no ?

Just an idea I’m putting on the table here …

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.

https://createnewwiki.fandom.com/wiki/Special:CreateNewWiki

Some users have already done this. Neither uses a cloud-based solution however & both below could run as a /container theoretically :wink:
@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.

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.

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