CAPsMAN - CAP VLAN configuration example on help.mikrotik.com

In a perfect world the examples given on Mikrotik help pages should be:

  1. accurate
  2. easily reproducible
  3. understandable

It seems like this is not always the case.

I tried (of course failing) to understand fully the " CAPsMAN - CAP VLAN configuration example" given here:

Something must be missing (or it is unexplained).

I tried making a spreadsheet with a comparison of the settings of the CAPsMAN and of two CAPs (one with wifi-qcom-ac and one with wifi-qcom) to highlight what I don't understand/cannot explain.

Hopefully, if someone can fill the voids/correct the mistakes/answer the doubts, the spreadsheet could become a good reference.

Capsman_example.zip (8.5 KB)

@jaclaz ,
Configuring the environments where you have AC and AX is a headache.
Also, provide more than 2 SIDs, causing another headache

The main problem is how to assign the VLAN ID to the Wi-Fi device. In AX config, you can have multiple VLAN_IDs per WiFi interface, but in AC, you can have only 1 (one VLAN_ID.

I used Milrotik help only as a reference and to understand ideas. After spending many hours testing and exploring config concepts, I have my own universal config for AX and AC devices that separates SSIDs and VLANs.

Welcome on this thread, good morning, Monsieur De La Palice. :wink:

That is the whole point, it shouldn't be (as it seems to be now) either rocket science or brain surgery, with a touch of voodoo on top.

It would be nice if you could share this configuration, it might be an alternate way to better explain the (as I see it unresolved) problems everyone seems to be facing when attempting to use CAPsMAN/CAPs.

My main problem was the setup, where I have 1 SSID but many VLANs. On old wireless drivers, it wasn’t an issue. After using wifi-qcom and wifi-qcom-ac, I decided to forget the AC devices in my setup. Only in the lab I’m using for the tests.

For the config where we have SSID : VLAN → 1 : 1, and the config is for 3 SSIDs, then:

# CAPsMAN
/interface wifi channel
add disabled=no name=dfs skip-dfs-channels=10min-cac

/interface wifi security
add authentication-types=wpa2-psk,wpa3-psk disable-pmkid=yes disabled=no ft=yes ft-over-ds=yes management-protection=required name=sec_lab_main wps=disable
add authentication-types=wpa2-psk,wpa3-psk disable-pmkid=yes disabled=no ft=yes ft-over-ds=yes management-protection=required name=sec_lab_guest
add authentication-types=wpa2-psk,wpa3-psk disable-pmkid=yes disabled=no ft=yes ft-over-ds=yes management-protection=required name=sec_lab_iot wps=disable

/interface wifi steering
add disabled=no name=lab_stering rrm=yes wnm=yes

/interface wifi configuration
add channel=dfs country=Czech disabled=no name=cfg_lab_main_22 security=sec_lab_main ssid=lab steering=lab_stering
add channel=dfs country=Czech disabled=no name=cfg_lab_iot_33 security=sec_lab_iot ssid=iot steering=lab_stering
add channel=dfs country=Czech disabled=no name=cfg_lab_guest_44 security=sec_lab_guest ssid=guest

/interface wifi capsman
set enabled=yes interfaces=vlan66-lab-mgt require-peer-certificate=no upgrade-policy=none

/interface wifi provisioning
add action=create-enabled comment=2G disabled=no master-configuration=cfg_lab_main_22 name-format=ax_2G_%I slave-configurations=cfg_lab_iot_33,cfg_lab_guest_44 supported-bands=2ghz-ax
add action=create-enabled comment=5G disabled=no master-configuration=cfg_lab_main_22 name-format=ax_5G_%I slave-configurations=cfg_lab_iot_33,cfg_lab_guest_44 supported-bands=5ghz-ax

/interface vlan
add interface=lan_hex name=vlan22-lab_main vlan-id=22
add interface=lan_hex name=vlan33-lab_iot vlan-id=33
add interface=lan_hex name=vlan44-lab_guest vlan-id=44
add interface=lan_hex name=vlan66-lab-mgt vlan-id=66

/interface bridge
add frame-types=admit-only-vlan-tagged name=lan_hex port-cost-mode=short protocol-mode=none pvid=66 vlan-filtering=yes

/interface bridge port
add bridge=lan_hex interface=ether2-trunk internal-path-cost=10 path-cost=10 pvid=66

/interface bridge vlan
add bridge=lan_hex tagged=lan_hex,ether2-trunk vlan-ids=66
add bridge=lan_hex tagged=lan_hex,ether2-trunk vlan-ids=22,33,44

and

# AP
/interface wifi datapath
add bridge=cap_ax disabled=no name=dp_22 vlan-id=22
add bridge=cap_ax disabled=no name=dp_33 vlan-id=33
add bridge=cap_ax disabled=no name=dp_44 vlan-id=44

/interface wifi
set [ find default-name=wifi1 ] configuration.manager=capsman .mode=ap datapath=dp_22 disabled=no mac-address=48:xx:xx:xx:xx:01 name=wifi1_22
add configuration.mode=ap datapath=dp_33 disabled=no mac-address=4A:xx:xx:xx:xx:13 master-interface=wifi1_22 name=wifi1_33
add configuration.mode=ap datapath=dp_44 disabled=no mac-address=4A:xx:xx:xx:xx:14 master-interface=wifi1_22 name=wifi1_44
set [ find default-name=wifi2 ] configuration.manager=capsman .mode=ap datapath=dp_22 disabled=no mac-address=48:xx:xx:xx:xx:02 name=wifi2_22
add configuration.mode=ap datapath=dp_33 disabled=no mac-address=4A:xx:xx:xx:xx:23 master-interface=wifi2_22 name=wifi2_33
add configuration.mode=ap datapath=dp_44 disabled=no mac-address=4A:xx:xx:xx:xx:24 master-interface=wifi2_22 name=wifi2_44

/interface wifi cap
set discovery-interfaces=vlan66-lab_mgt enabled=yes lock-to-caps-man=no slaves-static=yes

/interface vlan
add interface=cap_ax name=vlan22-lab_main vlan-id=22
add interface=cap_ax name=vlan33-lan_iot vlan-id=33
add interface=cap_ax name=vlan44-lab_guest vlan-id=44
add interface=cap_ax name=vlan66-lab_mgt vlan-id=66

/interface bridge
add frame-types=admit-only-vlan-tagged name=cap_ax pvid=66 vlan-filtering=yes

/interface bridge port
add bridge=cap_ax frame-types=admit-only-vlan-tagged interface=ether1 pvid=66
add bridge=cap_ax interface=wifi1_22 pvid=22
add bridge=cap_ax interface=wifi2_22 pvid=22
add bridge=cap_ax interface=wifi1_33 pvid=33
add bridge=cap_ax interface=wifi1_44 pvid=44
add bridge=cap_ax interface=wifi2_33 pvid=33
add bridge=cap_ax interface=wifi2_44 pvid=44

/interface bridge vlan
add bridge=cap_ax tagged=cap_ax,ether1 vlan-ids=66
add bridge=cap_ax tagged=cap_ax,ether1 untagged=wifi1_22,wifi2_22 vlan-ids=22
add bridge=cap_ax tagged=cap_ax,ether1 untagged=wifi1_33,wifi2_33 vlan-ids=33
add bridge=cap_ax tagged=cap_ax,ether1 untagged=wifi1_44,wifi2_44 vlan-ids=44

/system identity
set name=CapAX-lab

Of course, don’t forget to add ā€œpassphrase=ā€œ to CAPsMAN :). The AP config is from CAP AX, and the same is true for AC.
It is important to properly configure the main and virtual interfaces on the AP. If you check the forum, you can find the above configuration in one of the threads about migration from the old wireless to the new one.

The snippets from Mikrotik help page have 2 characteristics:

  1. The configurations on CAPs are different on AX and AC devices
  2. The configuration on the CAPsMAN needs some additions if a CAP AC Is used

Are you telling me that the above Is wrong and that we can have a "same" configuration on the two CAPs and that also the CAPsMAN configuration can be the same for both AC and AX?

I have been there and done that and I did have a hybrid setup with both AC and a single AX devices. But I then made my wallet man up and sort this nonsense out, so my main setup is AX devices only. The AC device then became part of another setup which works but lives in the cardboard box.

The CAPs should have the appropriate setup according to whether they are AC or AX, which is straightforward enough, but then you might have to modify it according to the CAPsMAN setup.

My recall is possibly faulty from the time of the hybrid setup, because I vowed never to do it again and couldn't be bothered to remember carefully [== promptly mostly forgot], but I had 2 iterations at this :

  1. First time I set up the CAPsMAN for AC units and provisioned the AC and AX units alike. Because AC units don't accept datapath configuration from the CAPsMAN, I had to do the vLAN plumbing manually on both AC and AX units
  2. On the second iteration, I got nearer to the issues that you are concerned with and did separate configurations for AC and AX. I had a House SSID and a Guest SSID common to all CAPs. The setup is tidier to explain in terms of WebFig/WinBox, in that I did Security configurations for House and Guest SSIDs, which was common to AC and AX and I could do a datapath configuration for the AX unit [I only have a vLAN for the Guest SSID]. So I then set upa Guest-AC and a Guest-AX Configuration [can't remember whether I did the same for House - I think I did, but whether I needed to, I can't remember]. And I provisioned separately for AC and AX.

Edited to Add:
I don't have an IoT, but if I did, I would probably get the CAP ac out of the cardboard box, together with its associated CAPsMAN unit and use that. There is nothing greatly wrong with AC under CAPsMAN, but I would not now mix AC and AX under the same CAPsMAN.

No, I did not write that the documentation is wrong.

I spent many hours working on a configuration to get AC and AX onto a single network using new drivers. Please see the help page. There, you can only find descriptions for 2 SIDs: main and quest. Documentation provides simple examples; if you want a more complex setup, it can cause issues.

In AX setup, when you start AP, you have virtual interfaces, as well as bridge ā€œvirtualā€ ports and VLANs created and assigned dynamically. But you have to remember when a particular option was implemented.
In AC, you have to create a virtual Wi-Fi device and assign the VLAN_ID directly.

Next point, if you follow the documentation, you have to remember to have separate configs for AC and AX. You pointed out the differences in Excel. Also, remember to identify the AC/AX device for provisioning correctly. If you follow the default configs and have both types of devices in your retwork, be prepared for surprises.

I mix the setup for AX and AC, but I like a tidy, clean config, and to generate the configuration for many devices in the same manner. Also, in my config, I have better control over what arrives in logs when a Wi-Fi device is associated.

By default, I use AX only because I have only 1 SSID, and with the access list, I can assign devices to a particular VLAN.

@pmastal
I don't get It.
You posted a CAPsMAN and a CAP (AX only?) configuration, where Is the "other" CAP (AC only?) configuration?
I can try to compare your posted configurations against those already in the speeadsheet, but I am not expert enough to produce the sound of one hand clapping ...

@DuctView
Interesting, but irrelevant for the scope of this thread, which Is exactly about this mixed environment.
The advise to go all in on AX or on AC might be a very wise one, but doesn't help to explain the examples (which Is what I am trying to do).

Gee thanks. I have told you that I have done it in [1]. And I have told you in WebFig/WinBox terms under [2] what the difference is.

Exactly - for the AP configuration, AX and AC are the same.

OK. :slightly_smiling_face:

Questions/doubts (on CAPsMAN configuration):

  1. you have an interface called "ether2-trunk" that I cannot see defined anywhere
  2. the above "ether2-trunk" is the ONLY interface added to the bridge in /interface bridge port (while the original exanple adds "normally" ether2-5 to the bridge)
  3. you have - besides a third VLAN for iot, a "mgmt" VLAN (66), for the simple example comparison I need to remove them, for the iot vlan it is easy, but I am not too sure how to remove the 66
  4. you have a /interface wifi datapath called "dp_noVLAN" defined but disabled, does itr serve any purpose?

Your posted configuration (CAPsMAN) has a typo here:

/interface wifi configuration
add channel=dfs country=Czech disabled=no name=cfg_lab_main_22 security=sec_lab_main ssid=lab steering=lab_stering
add channel=dfs country=Czech disabled=no ame=cfg_lab_iot_33 security=sec_lab_iot ssid=iot steering=lab_stering
add channel=dfs country=Czech disabled=no name=cfg_lab_guest_44 security=sec_lab_guest ssid=guest

on second setting "ame" shoudl be of course "name".

So, I did not set all the config from the CAPsMAN configuration. It is my lab system where I’m testing different ideas and options. I only provided what was needed to catch the idea.

ether2-trunk - as name = trunk, this port is to connect the CAPsMAN ←> CAP.
VLAN_ID=66 is my management VLAN for both devices. Also, I did not write the full setup, only the idea purposes. As you can see in the example configuration, the CAP is bound to VLAN(66). In my network, I have a separate VLAN only for CAPsMAN traffic.
"dp_noVLAN" - as I wrote, I copied it from my lab system and forgot to remove it. Original post fixed.

Typo fixed, I did not catch one letter missing.

Here's my working setup. It consists of:

  • CAPsMAN device, running on a wired-only router (it's a hAP ac2 acually, but doesn't have wifi-qcom-ac driver installed, so that makes it wired-only)
  • AC device - Audience as CAP device. It has wifi-qcom-ac driver installed.
  • AX device - wAP ax as CAP device. It has wifi-qcom driver installed

All devices are currently running ROS 7.21.4 (long-term). CAPs were upgraded from CAPsMAN (I've downloaded required packages and put it on CAPsMAN before upgrading CAPsMAN device).

I'm running a few VLANs, there are two VLANs relevant to WiFi setup: main LAN (VLAN ID 42) and guest access (VLAN ID 41).

I've set up VLANs on CAPsMAN on swithc chip, so bridge is not VLAN-aware.

Here's relevant part configuration of wired part of CAPsMAN:

/interface ethernet
set [ find default-name=ether1 ] name=ether1-trunk
...
/interface ethernet switch port
set 0 vlan-mode=secure
...
set 5 vlan-mode=secure   # this is switch-cpu "port"
/interface ethernet switch vlan
...
add independent-learning=yes ports=switch1-cpu,ether1-trunk switch=switch1 vlan-id=99
add independent-learning=yes ports=switch1-cpu,ether1-trunk switch=switch1 vlan-id=42
add independent-learning=yes ports=switch1-cpu,ether1-trunk switch=switch1 vlan-id=41
/interface bridge
add admin-mac=BA:69:F4:xx:yy:zz auto-mac=no name=bridge
/interface bridge port
add bridge=bridge interface=ether1-trunk
/interface vlan
add interface=bridge name=vlan-41 vlan-id=41
add interface=bridge name=vlan-42 vlan-id=42
add interface=bridge name=vlan-99 vlan-id=99

And then the WiFi CAPsMAN part of config ...
I'm setting APs with statically configured frequencies and I'm setting them up in /interface/wifi/channel ... which I'm not including as it's not relevant to the discussion.
First the part which is common for both AX and AC CAP clients:

/interface wifi security
add authentication-types=wpa2-psk,wpa3-psk connect-priority=0/1 dh-groups=19,20,21 \
    disable-pmkid=yes encryption=ccmp,ccmp-256 ft=yes ft-over-ds=no \
    ft-preserve-vlanid=no group-key-update=5m name=wpa2wpa3 wps=disable \
    passphrase=<redacted>
/interface wifi capsman
set enabled=yes interfaces=vlan-99 package-path=usb1/packages upgrade-policy=suggest-same-version

Here's part, relevant for AX clients (which can deal with VLAN settings on datapath):

/interface wifi datapath
add bridge=bridge comment=LAN name=datapath42 vlan-id=42
add bridge=bridge client-isolation=yes comment="guest WiFi" name=datapath41 vlan-id=41
/interface wifi configuration
add channel=2GHz-13 comment="2GHz ch13 42" country=<redacted> datapath=datapath42 \
    mode=ap multicast-enhance=enabled name=2GHz-13-42 security=wpa2wpa3 ssid=mkxNet
add channel=5GHz-52 comment="5GHz ch52 42" country=<redacted> datapath=datapath42 \
    mode=ap multicast-enhance=enabled name=5GHz-52-42 security=wpa2wpa3 ssid=mkxNet
add datapath=datapath41 mode=ap multicast-enhance=enabled name=slave-41 \
    ssid="I\E2\9D\A4MikroTik"

/interface wifi provisioning
# single SSID on 2GHz interface
# MAC belongs to wAP ax 2GHz interface
add action=create-enabled comment="wAP 2Ghz" master-configuration=2GHz-13-42 \
    radio-mac=F4:1E:57:aa:bb:cc
# 2 SSIDs on 5GHz interface, master configuration is same SSID as on 2GHz interface,
# slave is guest SSID; MAC belongs to wAP ax 5GHz interface
add action=create-enabled comment="wAP 5Ghz" master-configuration=5GHz-52-42 \
    radio-mac=F4:1E:57:aa:bb:cd slave-configurations=slave-41

The above portion of config makes configuration on wAP ax working. Note: setting provisioning action=create-enabled is not necessary, I'm using it to get persistent interfaces (on CAPsMAN as well) so I can change interface names on CAPsMAN to more descriptive ones.

Other relevant configuration, set on (each) wAP ax (or any other AX) client, includes:

/interface bridge
add admin-mac=F6:1E:57:xy:yz:zw auto-mac=no frame-types=admit-only-vlan-tagged name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge frame-types=admit-only-vlan-tagged interface=ether1
/interface bridge vlan
add bridge=bridge comment=MGMT tagged=bridge,ether1 vlan-ids=99
add bridge=bridge tagged=ether1 vlan-ids=42
add bridge=bridge tagged=ether1 vlan-ids=41
/interface wifi configuration
add manager=capsman name=capsman
/interface wifi cap
set discovery-interfaces=vlan-99 enabled=yes
/interface wifi datapath
add bridge=bridge name=default

And now the Audience part of configuration ... which is pretty much more complicated. Partially as it's got 3 radios and (unlike on wAP ax) the guest SSID runs on its own physical radio. But the main complexity is in VLAN setup.

Here's the CAPsMAN configuration, specific for AC CAP:

/interface wifi datapath
add bridge=bridge client-isolation=yes comment="no VLAN ID" name=datapath-noVID
/interface wifi configuration
add channel=2GHz-9 comment="2GHz ch9 no VLAN ID" country=<redacted> datapath=datapath-noVID \
    mode=ap multicast-enhance=enabled name=2GHz-9-noVID security=wpa2wpa3 ssid=mkxNet
add channel=5GHz-low-20 comment="5GHz low guest no VLAN ID" country=<redacted> \
    datapath=datapath-noVID mode=ap multicast-enhance=enabled name=5GHz-low-41-novid ssid="I\E2\9D\A4MikroTik"
add channel=5GHz-100 comment=5GHz-100-noVID country=<redacted> datapath=datapath-noVID \
    mode=ap multicast-enhance=enabled name=5GHz-100-noVID security=wpa2wpa3 ssid=mkxNet
...
/interface wifi provisioning
add action=create-enabled comment="Audience 2GHz" master-configuration=2GHz-9-noVID radio-mac=2C:C8:1B:bb:cc:de
add action=create-enabled comment="Audience 5GHz low" master-configuration=5GHz-low-41-novid radio-mac=2C:C8:1B:bb:cc:dd
add action=create-enabled comment="Audience 5GHz high" master-configuration=5GHz-100-noVID radio-mac=2C:C8:1B:bb:cc:df

There are two main points of the AC-specific part of config:

  1. use of datapath profile without vlan-id set
  2. use of action-create-enabled on provisioning rules (the relevance will become apparent below).

Other relevant configuration, set on (each) Audience (or any other AC) client, includes:

/interface bridge
add admin-mac=2E:C8:1B:bb:cc:ae auto-mac=no frame-types=admit-only-vlan-tagged \
    name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge frame-types=admit-only-vlan-tagged interface=ether1
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=wifi1 pvid=42
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=wifi2 pvid=41
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=wifi3 pvid=42
/interface bridge vlan
add bridge=bridge comment=MGMT tagged=bridge,ether1 vlan-ids=99
add bridge=bridge comment=LAN tagged=ether1 vlan-ids=42
add bridge=bridge comment=guest tagged=ether1 vlan-ids=41
...
/interface wifi cap
set discovery-interfaces=vlan-99 enabled=yes slaves-static=yes
/interface wifi configuration
add manager=capsman name=capsman

Notes:

  1. there's no datapath defined as there's no need for it ... and the reason is in the next bullet:
  2. since CAPsMAN provisioning includes action-create-enabled, it'll enable (or create in case of slave interfaces) interface on CAP ... and these interfaces will be persistent (unlike default action, which is create-dynamic-enabled and those interfaces are not persistent). Which makes it possible to manually add them as bridge port on CAP device ... which in turn allows for setup the VLAN properties of these interfaces.

The end effect on AX CAP client is this:

[user@wapax] /interface/bridge/port> print 
Flags: D - DYNAMIC
Columns: INTERFACE, BRIDGE, HW, HORIZON, TRUSTED, FAST-LEAVE, BPDU-GUARD, EDGE, 
         POINT-TO-POINT, PVID, FRAME-TYPES
#   INTERF  BRIDGE  HW   HORI  TR  FA  BP  EDGE  POIN  PVID  FRAME-TYPES           
0   ether1  bridge  yes  none  no  no  no  auto  auto     1  admit-only-vlan-tagged
1 D wifi1   bridge       none  no  no  no  auto  no      42  admit-all             
2 D wifi2   bridge       none  no  no  no  auto  no      42  admit-all             
3 D wifi7   bridge       none  no  no  no  auto  no      41  admit-all

[user@wapax] /interface/bridge/vlan> print 
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED
;;; MGMT
0   bridge        99  bridge        
                      ether1        
1   bridge        42  ether1        
2   bridge        41  ether1                     
;;; added by wifi
5 D bridge        42  wifi2             

Note the "D" flag on all wifi bridge ports ... which means they were added as bridge ports dynamically, due to CAPsMAN privisioning and properly used datapath.
AFAIK this kind of setup is slightly wrong ... because wifi-qcom driver is actually tagging frames (either with vlan-id as set on datapath or using VID value set in access-list or ...) but bridge port still has PVID set.
The weird part is print out of /interface/bridge/vlan (yes, it's missing items #3 and #4 because they're irrelevant to shown configuration). It's missing entries for wifi1 (should be tagged with VID 42) and wifi7 (should be tagged with VID 41).
I guess it's a bit harder to make things correct, specially with /interface/bridge/vlan settings if we allow manual settings of VID other than in datapath.

And on AC CAP client it's like this:

[user@audience] /interface/bridge/port> print 
Flags: I - INACTIVE
Columns: INTERFACE, BRIDGE, HW, HORIZON, TRUSTED, FAST-LEAVE, PATH-COST, INTERNAL-PATH-COST, BPDU-GUARD, EDGE, 
         POINT-TO-POINT, PVID, FRAME-TYPES
#   INTERFACE  BRIDGE  HW   HORIZON  TR  FA  PA  IN  BP  EDGE  POIN  PVID  FRAME-TYPES                            
0   ether1     bridge  yes  none     no  no  10  10  no  auto  auto     1  admit-only-vlan-tagged                 
1   wifi2      bridge       none     no  no          no  auto  auto    41  admit-only-untagged-and-priority-tagged
2   wifi1      bridge       none     no  no          no  auto  auto    42  admit-only-untagged-and-priority-tagged
3   wifi3      bridge       none     no  no          no  auto  auto    42  admit-only-untagged-and-priority-tagged

[user@audience] /interface/bridge/vlan> print 
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; MGMT
0   bridge        99  bridge                          
                      ether1                          
;;; LAN
1   bridge        42  ether1                          
;;; guest
2   bridge        41  ether1                          
;;; added by vlan on bridge
3 D bridge        42  bridge                          
;;; added by pvid
4 D bridge        42                  wifi1           
                                      wifi3           
;;; added by pvid
5 D bridge        41                  wifi2 

Note the frame-types and lack of "D" flag. And note the "completeness" of VLAN setup :wink:

@pmastal
Ah, well, then your posted configuration is not actualy verified/tested/whatever (in the sense that is not directly comparableto the base example).
The ether2-trunk (if it is just the single ether2 renamed as "ether2-trunk")makes no sense to me if there is more than one CAP connected.

@mkx
Thanks, but your configuratrion snippets are as well going well over my head.

I wanted to build upon the original Mikrotik examples, but from the replies posted it seems to me like you took (evidently for good reasons) completely diverging paths from those examples.

I will need to dissect your posted snippets to re-convert them to the basic examples (provided that I will be able to).

Thanks for the create-enabled tip that - when used - no datapath is then needed.

I guess overall we are back to the original problem (or non-problem) that in Mikrotik configurations you can obtain the same of similar results using two or three different methods and almost invariably people use something different from the official (as said scarce and often mis-documented) help examples.

I'll see what I can get from merging/comparing your configurations, thanks a lot to both.

If there’s one thing I’d like Mikrotik to invest in, it’s an intern to review all of the documentation and classify it with tags for RouterOS versions and dependencies. There’s still way too much stuff that is RouterOS 6 specific and CAPsMAN stuff falls right into this camp. Screenshots showing CAPsMAN as an option on the left menu are clearly RouterOS 6 dependent and should not be left in the current documentation, but referenced as subpages clearly stating #RouterOS6 using these wifi packages.

Also, a lot more simple recipes for many Ā« standard Ā» types of deployments would help onboard new users, again, tagged to the appropriate versions so you don’t get 75% done before discovering you’re on the wrong path.

Hey, wait, the honorific title of Monsieur De La Palice has already been attributed to pmastal.
All you can have now is Captain Obvious :woozy_face:.

LOL - I’ll take it :grinning_face_with_smiling_eyes:

In my configuration, you don’t find, for example, VLANs (dhcp/network) definitions and other stuff. You can find partial information on how to set up the CAPsMAN + AP, as well as parts related directly to the bridge configurations, so you don’t miss them.
My configuration works - I’m testing it before I share. If something is disabled, I should not present it. And now it is fixed in the original post.

Yep, I don't doubt in the least that it works just fine in your particular setup, but this particular setup is different from the one in the reference example, so I need to somehow "normalize" it to make it comparable.

What do you wish to compare? The delivered example is exactly the idea from the documentation for AC. So, the AX and AC configuration for CAP and CAPsMAN is ā€œthe sameā€.
When provisioning, you can (and I’m recommending) check whether you have the CAP AC or AX.

Below you have examples

For CAPsMAN:

/interface wifi provisioning
add action=create-enabled comment=2G disabled=no master-configuration=cfg_lab_main_22 name-format=ax_2G_%I slave-configurations=cfg_lab_iot_33,cfg_lab_guest_44 supported-bands=2ghz-ax identity-regexp=CapAX.*
add action=create-enabled comment=5G disabled=no master-configuration=cfg_lab_main_22 name-format=ax_5G_%I slave-configurations=cfg_lab_iot_33,cfg_lab_guest_44 supported-bands=5ghz-ax identity-regexp=CapAX.*
add action=create-enabled comment=2G disabled=no master-configuration=cfg_lab_main_22 name-format=ac_2G_%I slave-configurations=cfg_lab_iot_33,cfg_lab_guest_44 supported-bands=2ghz-ac identity-regexp=CapAX.*
add action=create-enabled comment=5G disabled=no master-configuration=cfg_lab_main_22 name-format=ac_5G_%I slave-configurations=cfg_lab_iot_33,cfg_lab_guest_44 supported-bands=5ghz-ac identity-regexp=CapAC.*

On CAP AX

/system identity set name=CapAX-lab

On CAP AC

/system identity set name=CapAC-lab

The most important stuff to understand:

  1. On CAP, you have to create the virtual interfaces with ā€œstrictā€œ MAC
  2. It is important to order the virtual interfaces as they are ā€œbound ā€œ to VLAN_ID and to provisioning order on CAPsMAN
  3. On CAPsMAN, ā€œaction=create-enabledā€ is used to avoid recreating Wi-Fi devices.

Still a problem? Mkx perfectly shows that the CAP AX configuration creates dynamic objects, which you don’t find in mine.