I have a couple of cAP ax units arriving in a few weeks so I wanted to prep my network for the Wifiwave2 package with CAPsMANv2.

It's pretty straightforward but requires some extra work, particularly if you have multiple SSIDs and those SSIDs are on VLANs other than VLAN 1. In the example below we have two SSIDs, with the first /master SSID on VLAN 1 (PVID 1) and the second/slave SSID on VLAN 10. Note that I do not go into detail what the SSID names are nor do I define the Master and Slave configurations here, as it's outside the scope of this post.

With CAPsMANv1, all the bridge port additions and VLAN settings on access points were configured automatically. In CAPsMANv2, they currently ( as of v7.8 ) are not. This is particular to radios that only support 802.11ac as I have not yet tested radios with 802.11ax support. The documentation seems to suggest that it *does* take care of it automatically on those radios, but it's best to be aware of the potential issue.


If you try to define VLANs in the datapath settings within a configuration profile, and then assign this configuration to an access point that only supports 802.11ac, you will receive an error of "vlan-id configured but interface does not support assigning vlans". The configuration I provide below resolves this issue (assuming you also remove the VLAN ID from the CAPsMAN configuration profile, as I have not tested this if you leave the setting in).

CAPsMAN config
Note that we do not define VLANs for the access point's WiFi interfaces here. This is all configured on the CAP (access point).
CAP (access point) config
In this example, the access point connection to other switches is ether1. On your device the slave interface (wifi6) could be named wifi5 or something else. It's dynamically created. The point being that you must manually add the interface as a port on the bridge, including its PVID. Some disclaimers are necessary. This configuration leaves out a whole bunch of potential settings such as radio channels and security settings. It's not intended to provide guidance on those, which is why they are not here. That is not to say that you should not correctly define these settings to meet the needs of your radio environment.

The only current way to get vlan and dynamic interfaces working on caps with capsman 2 is to disable vlan filtering on cap bridge.
Then it will work.

Will be fixed in a subsequent release, I was told by support.

The only current way to get vlan and dynamic interfaces working on caps with capsman 2 is to disable vlan filtering on cap bridge.
Then it will work.

That's a short statement with a lot potential ramifications. For example, the PVID setting applied to ports in the bridge has no effect unless Bridge VLAN filtering is turned on. Without this, I don't even know how I would go about making sure that the secondary/slave interface was added to the right VLAN so that packets from the cap are tagged as they are sent to the router. Did you receive guidance on this? It sounds extremely complex to manage.

As said: Was instructed so by support.
I couldn't get it working so made a ticket.
After a bit of back and forth this is what they told me.
And it works.
Confirmed by other users, see 7.9rc thread.

The only current way to get vlan and dynamic interfaces working on caps with capsman 2 is to disable vlan filtering on cap bridge.
Then it will work.

Will be fixed in a subsequent release, I was told by support.

Even without capsman, that's the way to have dynamic VLAN assignment by the driver (access list or RADIUS attribute based). The wireless driver must have access to all the needed VLAN's as tagged. So disabling vlan filtering will make the bridge as a dump switch and forward all tagged packets to and from the wireless driver untouched. I expect defining the wireless driver port on the bridge as trunk or hybrid should work as well.
Makes sense to me. Don't see how this "per device or authenticated user" VLAN will ever work with VLAN's handled only by the bridge, unless they are static.

I understand what you say.

But when you do not use capsman and you want to use vlan on that device, it is completely different.
Then you need to treat the wifi port just like any other ports.
Also when using static interfaces for capsmanv2, it works that way (wifi1 and wifi2 interfaces).

Only when using slave interfaces and/or dynamic created interfaces, it needs to be without vlan filtering on bridge.
And there is only 1 setting on the bridge to do the filtering: on or off for everything.
At least, that's what my testing showed. I have disabled this workaround, waiting for the final solution.

Yep. Correct. What I wanted to indicate, is that the bridge VLAN and the wifi interface VLAN must be set to untag ( and tag in the receiving direction) the traffic just once.

Either done in the bridge (VLAN filtering on, wifi interface untagged) or it is done in the wifi driver (so the traffic from and to the bridge is tagged, either by adding the wifi interface as tagged to the VLAN, or by disabling the VLAN handling by the bridge (VLAN filtering not enabled)) If CAPsMAN v2 , which is always doing local forwarding, is not able to set the wifi interface as tagged for that VLAN in the bridge, then this will not work with bridge VLAN filtering enabled. (Bridge default is adding interfaces as untagged)

You know I'm not an CAPsMAN fan or user, and this again is for me an indication CAPsMAN limits the configuration options.

I can confirm, that this issue still exists.

The only current way to get vlan and dynamic interfaces working on caps with capsman 2 is to disable vlan filtering on cap bridge.
Then it will work.

Will be fixed in a subsequent release, I was told by support.

Has this been solved ? Now it is 7.11 stable, and have you tried enabling vlan filtering on CAP bridge ?

But when you do not use capsman and you want to use vlan on that device, it is completely different.
Then you need to treat the wifi port just like any other ports.
Also when using static interfaces for capsmanv2, it works that way (wifi1 and wifi2 interfaces).

Only when using slave interfaces and/or dynamic created interfaces, it needs to be without vlan filtering on bridge.
And there is only 1 setting on the bridge to do the filtering: on or off for everything.
At least, that's what my testing showed. I have disabled this workaround, waiting for the final solution.

Can confirm, that creating static interfaces with CAPsMAN action, allows to add these created wifi interfaces to bridge as any other port. However, one must also not set datapath, otherwise the wifi interface will be added to the bridge as dynamic port - can't set VLAN settings for it. Works well also for slave interfaces.

You know I'm not an CAPsMAN fan or user, and this again is for me an indication CAPsMAN limits the configuration options.

Well, CAPsMAN is required for successful roaming according to the docs - https://help.mikrotik.com/docs/display/ROS/WifiWave2:

For a client device to successfully roam between 2 APs, the APs need to be managed by the same instance of RouterOS. For information on how to centrally manage multiple APs, see CAPsMAN

Which is somewhat in a contradiction with the first half of this statement from the docs:

WifiWave2 CAPsMAN only passes wireless configuration to the CAP, all forwarding decisions are left to the CAP itself - there is no CAPsMAN forwarding mode.

As it seems so, that WifiWave2 CAPsMAN is not just passing configuration, but also does some communication between CAPsMAN a CAPs in order to get roaming (802.11r) to work successfully.

Well, CAPsMAN is required for successful roaming according to the docs - https://help.mikrotik.com/docs/display/ROS/WifiWave2:

For a client device to successfully roam between 2 APs, the APs need to be managed by the same instance of RouterOS. For information on how to centrally manage multiple APs, see CAPsMAN

.
Yes, but this "same instance of RouterOS" is only needed for Fast Roaming (FT, 802.11r) AFAIK. Because Roaming works between independent MT AP's, but needs the authentication time before restarting the data flow. If the AP's are on the same L2 network, the (DHCP) IP address remains valid, and is not renewed. The NATted session in the edge router towards Internet remains the same. This is an acceptable delay for many applications, but not for "Voice".

(I expect the authentication to be done in the CAPsMAN controller the only RouterOS instance that matters here. 802.11r standard tells about pre-authenticating different instances, but not with Mikrotik ?)
source: (https://www.tanaza.com/wifi-fast-roaming/)

Because Roaming works between independent MT AP's, but needs the authentication time before restarting the data flow. If the AP's are on the same L2 network, the (DHCP) IP address remains valid, and is not renewed. The NATted session in the edge router towards Internet remains the same. This is an acceptable delay for many applications, but not for "Voice".

This makes sense. A re-connection to a different AP on the same L2 network should result in device still being available under the same MAC address in same L2 broadcast domain, just at different physical/wire/wireless location. Therefore L3 should remain unaffected, or at least things that didn't timeout until the device got re-connected.

Yes, but this "same instance of RouterOS" is only needed for Fast Roaming (FT, 802.11r) ...

(I expect the authentication to be done in the CAPsMAN controller the only RouterOS instance that matters here. 802.11r standard tells about pre-authenticating different instances, but not with Mikrotik ?)

What about 802.11k and 802.11v? Do those still work?

Without centralized AP configuration via CAPsMAN, my devices were holding onto distant AP with weak signal for too long. Practically, until the signal was completely lost, even if the closest AP was literally 1 meter away, and the connection speed was like 1Mbit with many packets lost (iperf3 testing to a host connected on gigabit ethernet - almost full gigabit speed via wire).

Has this been solved ? Now it is 7.11 stable, and have you tried enabling vlan filtering on CAP bridge ?

No, it hasn't been solved. At least, not for hAP ac³. Though, I'm thinking to replace it with hAP ax², as hAP ac³ is way too big black thing, that attracts lots of attention.

Tried again today to see if the VLAN issue was fixed but no joy.

In my setup I have a hAP AC2 and 2x cAP AC units. I was able to do the workaround for the cAP AC's but the hAP AC2 will not accept the workaround being the router as well so I have had degraded wifi signal for some time now.

Please add this feature back
Getting to the point of considering rolling back to 7.12 over this

*sigh* on step forward, one step back. Experimenting with upgrading to CAPsMANv2 with legacy cAP ac devices. Tempted to go back to legacy wireless driver! Earlier posts here suggest this will be fixed in later versions but a year later and I've hit the same problem. Is there a definitive article on how to get a guest VLAN working? The suggestions early one are for the wave2 syntax so bit reluctant to even try if it's all changed.

Is the workaround to configure the VLAN on the cAP ac itself? I thought that all the settings were disabled when using CAPsMAN?

When not using any other vlan port on cap, you can use datapath settings in capsman controller.
Nothing to be done on cap.

Brain is too frazzled for this weekend. Will come back more VLAN stuff after a night off!

robmaltsystems, hi, any luck for guest VLAN? Iam also have a few issues with this on my wAP ac.

Haven't had chance to do the research yet. Real life keeps getting in way... I have the lab setup though.

Alright,

so please bear with me here.

I just bought two CAP ax units. I have no idea what wifiwave2 is (and neither my google search results nor Mikrotiks documentation is helping), but I joined them to CAPSMAN on a separate routerOS 7.14 device.

I tried pushing vlan to slave devices using configuration profiles on CAPSMAN, but this did not work.

Do I understand correctly that I should remove everything from the datapath section of the configuration profile in CAPSMAN, and instead set the VLAN's directly on the wifi devices in routerOS on the CAPS?

Right now they say "Managed by CAPSMAN" in red, and a lot of stuff is greyed out and can't be touched as a result.

I am gathering by what I have read here that if I remove the datapath stuff from the CAPSMAN configuration I should be able to set all of this directly on the devices and it will work?

I appreciate your help in determining if I have understood this correctly.

Thanks,
Matt


Edit: I just removed the configuration in CAPSMAN from the slave devices, and went to look on the CAPs themselves to see if I could add the VLAN under datapath, but it is still blank.

It says that they are "Dynamic" (but I have never added any provisioning?)

Maybe I need to remove the slaves on the CAPSMAN side, and then recreate the slaves on the CAPs?

Again, appreciate any input anyone might have.

From what I know and have red:

- cAP ax: reset config and set it in CAPs mode (this is enough)
- CAPsMAN: config datapaths with corresponding VLAN id's

Use a hybrid port with management VLAN untagged, Corporate and Guest tagged.
Don't use VLAN id 1 (implicitly or explicitly), when using VLAN's.

- cAP ax: reset config and set it in CAPs mode (this is enough)
- CAPsMAN: config datapaths with corresponding VLAN id's

Use a hybrid port with management VLAN untagged, Corporate and Guest tagged.

Just to clarify: the last line (regarding hybrid port) refers to port to which cAP ax devices are connected ... e.g. the separate ROS device.

If one starts with default CAP config on cAP ax, then bridge won't be configured in any particular way, so it'll be VLAN indifferent and hence ports will effectively be hybrid.

Thanks for the addition, @mkx. You are absolutely right. Only in very specific situations you want to adjust the CAPs coinfig. And this is not such a situation.

From what I know and have red:

- cAP ax: reset config and set it in CAPs mode (this is enough)
- CAPsMAN: config datapaths with corresponding VLAN id's

Use a hybrid port with management VLAN untagged, Corporate and Guest tagged.
Don't use VLAN id 1 (implicitly or explicitly), when using VLAN's.

Just to clarify: the last line (regarding hybrid port) refers to port to which cAP ax devices are connected ... e.g. the separate ROS device.

If one starts with default CAP config on cAP ax, then bridge won't be configured in any particular way, so it'll be VLAN indifferent and hence ports will effectively be hybrid.

So, again, let me just clarify here.

You are saying the CAP needs to be entirely in its default configuration or CAPSMAN won't be able to effectively configure it?

That makes sense I guess, but this leaves me with a little bit of a dilemma, and that is the CAP ax's absolutely moronic default configuration with ehter1 (the only PoE in port, which I need to use to power the damn thing) being set up by default to be a NAT:ed WAN port (??? Why God, Why?).

So I absolutely need to connect to port 1, but since it is NAT:ed and firewalled by default, and I can't touch default configs or CAPSMAN won't work, how will it communicate with CAPSMAN? Can it do so rethought it's WAN side?

CAPS Mode (and perhaps with No Default Configuration, but I think that is not mandatory) will set it to CAPS Mode. So, no NAT.

Caps mode is configuration.
So don't use No Config. Then you don't even get caps mode.

According to documentation:
Default ether1 will be set to DHCP client, ether2 will go to bridge with wireless interfaces.
All wireless interfaces listening for capsman controller.
No firewall, no NAT, nada...

But just a minute, I'll check what defconf says on one of my cAP AX devices.

One thing I know 100% for sure, you need to go to at least 7.10 on cAP AX (7.8 didn't have caps mode, 7.9 wifi is horrible).

Ah, they changed it (for the better)

From 7.14, /system default-configuration print

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

erlinden, hi, just want to clarify a few things about your message:

- cAP ax: reset config and set it in CAPs mode (this is enough)
- CAPsMAN: config datapaths with corresponding VLAN id's

The documentation says that the VLAN configuration at the moment still requires manual configuration for each AP managed by CAPsMAN, no matter 802.11ax or 802.11ac (different drivers used for each one): section CAPsMAN - CAP VLAN configuration example describes basic CAPsmAN config with VLAN in datapath, and CAP config for both drivers: CAP using "wifi-qcom" package and CAP using "wifi-qcom-ac" package. So its looks like If you want to use VLAN with CAPsMAN - you must manually configure each AP with VLAN, managed by CAPsMAN, despite the presence of a datapath config.

But in the beginning of this docs section there is a notice:

CAPs using "wifi-qcom" package can get "vlan-id" via Datapath from CAPsMAN, CAPs using "wifi-qcom-ac" package will need to use the configuration provided at the end of this example.

This is confusing: at the beginning of the section "CAPsMAN - CAP VLAN configuration example" it is said that with the "wifi-qcom" driver (802.11ax only) the AP will take the VLAN configuration from the datapath config (automatically, without any manual configuration?) ... aaand right below is the config for manual VLAN configuration for AP. WUT?!

So, is 802.ax AP's, managed by CAPsMAN, requires manual VLAN configuration, or it can be also managed by CAPsMAN's datapath config and no manual configuration is required?

It depends.

If your base LAN is default VLAN 1, no added config is needed on cap ax.
Wifi interfaces will take settings via datapath for vlan.

If your base vlan however is something else ( VLAN all the way), then added config is needed on cap for adding vlan itf to bridge. Bridge itself does not need to be set to vlan filtering though.
Discovery of capsman controller then also needs to be done via that vlan itf.

I really love MT for what is worth and the value it bring to a lot of company startup whether it's big and small, but this wireless radio/driver issues and capsman drama makes a lot of users look elsewhere, luckily for us we don't have use case for wireless other than out of band management connectivity. @ MT please polish and finish this now so that you can focus and move on some exciting and fun staff

Caps mode is configuration.
So don't use No Config. Then you don't even get caps mode.

According to documentation:
Default ether1 will be set to DHCP client, ether2 will go to bridge with wireless interfaces.
All wireless interfaces listening for capsman controller.
No firewall, no NAT, nada...

But just a minute, I'll check what defconf says on one of my cAP AX devices.

One thing I know 100% for sure, you need to go to at least 7.10 on cAP AX (7.8 didn't have caps mode, 7.9 wifi is horrible).

Alright. Now I am really confused.

So, as recommended, I went back and reset the CAP ax's units to CAPSMAN mode.

I then re-paired them with CAPSMAN on the CAPSMAN device.

I applied my main SSID config and security profiles. So far so good. Main SSID works.

In CAPSMAN I added slave interfaces for all four WIFI devices. Since someone suggested NOT using configuration profiles, I set up the SSID and VLAN ports (22 in my case) and applied the security profile directly on the interfaces.

For a brief second it looked like it was working. Devices seem to have connected and grabbed IP's from the DHCP server assigned to VLAN 22, but it was not to be. The devices were quickly non-responsive.

Then I logged in on each of the the CAPs themselves and clicked on the auto-generated bridge (bridgeLocal) and added vlan22 as follows:

Tagged: bridge and Ether1
Untagged: The two slave Wifi interfaces
The interesting part is, I was able to sign on to the SSID for VLAN22 from my phone, and it was able to grab an IP address in the IP range assigned to the DHCP on that VLAN.

The two stupid thermostats - however - while listed among the devices in the registration, do not appear to be coming online.

Maybe they need to be rebooted, or told to forget the SSID and re-authenticate?

Edit:

Yeah, so this is not working. I can't explain why my phone was able to log in and have it work, but nothing else seems to be able to. Not my laptop, or the damn thermostats this VLAN is intended for.

Edit2:

The phone connecting to the VLAN 22 SSID seems highly intermittent. It works sometimes, but not other times, and the pings on th elocal networkj to the phone when it is connected are all over the place from single digit ms all the way up to 200ms.

Anyone have any suggestions or pointers where I went wrong?

I'm honestly pretty close to returning these. According to Amazon I have until Tuesday to return them. If I can't get them to work in the next day, they are going to have to go back.

This really should not be this difficult. Mikrotik really needs to fix their wireless products.

holvoetn, so, if I want to congfigure guest network (separate SSID with custom name, security, channel, VLAN ID, etc.), and my basic VLAN ID is 1, Iam just can make datapath config with VLAN 1 for main network and, for example, datapath config with VLAN ID 2 for guest network, and all will works fine without any manual VLAN\bridge configs on AP?

Yes.
Provided ofcourse your router is properly configured to handle those vlans.

holvoetn, so, if I want to congfigure guest network (separate SSID with custom name, security, channel, VLAN ID, etc.), and my basic VLAN ID is 1, Iam just can make datapath config with VLAN 1 for main network and, for example, datapath config with VLAN ID 2 for guest network, and all will works fine without any manual VLAN\bridge configs on AP?

Yes.
Provided ofcourse your router is properly configured to handle those vlans.

I do not undersatand how you can say this when it is not working for so many people, myself included.

I have a confirmed functional router across multiple vlans. Previous AP's could assign SSID's and tag their traffic with VLAN tags and it worked perfectly.

Transitioning from previous other brand AP's to CAP AX's on same switch ports, identically configured, and my CAP ax's simply cannot do this. No matter what I try it fails.

I'm about ready to return them, because absolutely nothing I do works.

And I am not some beginner when it comes to networking and VLAN's. I've been doing this for over a decade across many different brands of networking devices. Never had a problem getting it to work until now.

Not wanting to sound too harsh but ... when it comes to Mikrotik, you start again at square one no matter what your previous experience is (and from what I read, it can sometimes be a disadvantage having deep knowledge of other eco-systems).

It's a quite steep learning curve (I'm still learning myself bits and pieces on almost a weekly basis) but once you get past the first hurdles, it's amazing what you can do with these devices.

What may help is to give some more info (you have never presented it before, unless I missed something ?):
- small drawing of network topology
- how are various devices connected to each other
- config of device acting as capsman controller and 1 of the cap devices (assuming they are all the same)
terminal
/export file=anynameyouwish
Move file to PC, edit and obfuscate sensitive info (public wan ip, passwords, ...)
Post here between [code] quotes for easier readability.

>It's a quite steep learning curve

Ain't that the truth!! The power and complexity of RouterOS is both a blessing and a curse. For the experienced, it's incredible. For the newbie, it's downright scary and off-putting. Which is part of the reason for the discussion going on about WinBox, controller, configuration etc.

Finally got tired of waiting and rolled back to the wireless package. The process was pretty painless and I have VLAN's working properly over capsman again. Think I will settle with WPA2 for the time being until this gets ironed out.

Well,

I wanted to make this work, but I got to the last day of my return window, and I had not yet been able to resolve my issue, so I decided to send them back.

I have popped my old Unifi 802.11ac units back in for the time being (and all the VLAN's work great again).

Going to have to think about what I do next. Maybe a set of Ruckus R650's. They cost more than 3x more, but if I can get them to work...

I'm still happy with my switches (using SwOS) but I don't think I'll be touching RouterOS again any time soon.

Well,

I wanted to make this work, but I got to the last day of my return window, and I had not yet been able to resolve my issue, so I decided to send them back.

I have popped my old Unifi 802.11ac units back in for the time being (and all the VLAN's work great again).

Going to have to think about what I do next. Maybe a set of Ruckus R650's. They cost more than 3x more, but if I can get them to work...

I'm still happy with my switches (using SwOS) but I don't think I'll be touching RouterOS again any time soon.

Nothing wrong with RouterOS, just the qcom-ac package is not up to par yet. I'm sure in time it will be. Mikrotik hasn't let me down yet