Hi,

I am relatively new to MikroTik and trying to configure the Wifi (Wave2) of my hAP ax².
In a first try I simply added the Wifi interface as a port to my bridge (Bridge.Ports) and also assigning the VLAN PVID via the Bridge.Port.
In the Wifi there is also the Datapath menu where it is possible to assign the Wifi interface to a bridge and specifying a VLAN ID.

Which of the ways of configuration should be used? What are the pros and cons?

My current feeling is also that there is really not much information about the Wave2 configuration available online. For example, the https://help.mikrotik.com/docs/display/ROS/WifiWave2 does not really help if you don't have the answers to my questions above.

Thanks for your help in advance,

Thomas

it's the same, wireless interfaces are placed manually in the bridge, or with datapath are dynamically joined to the bridge!

And what if I use CAPsMAN wave2? What’s the purpose of Datapath setting? Not clear at all as it doesn’t place wireless interfaces to the designated bridge.

Capsman2 (for wave2 devices) refers to CAP's local bridge in datapath configuration (capsman v2 doesn't (yet?) support capsman forwarding).

Ok. But there are no CAP’s bridges in the drop-down menu in CAPsMAN’s Datapath settings, only CAPsMAN’s local ones and selecting any of them doesn’t do anything.

No, CAPs' bridges won't be available in CAPsMAN config.

So what’s the purpose of this setting?

I have no handd-on experience with capsman v2 ... only with wifiwave2 (configured locally) and capsman v1.

Since wifiwave2 radio configuration locally and capsman v2 share same configuration tree, there's some sense in having capsman bridges listed in drop-down under datapath menu. I guess it's a shortcoming of GUI, in CLI one types-in name of bridge (regardless if it's on same device or on CAP device). I'm not sure if it's possible to type-in the name of bridge in GUIs ...

No, it's not possible. So your advice is to do it via CLI?

If you understood my previous post in any other way, then I failed to make my intention clear

Hi Thomas,

When it comes to configuring the WiFi (Wave2) of your hAP ax², there are a few ways to do it. One way is to add the WiFi interface as a port to your bridge and assign the VLAN PVID via the Bridge.Port, which you have already tried. Another way is to use the Datapath menu to assign the WiFi interface to a bridge and specify a VLAN ID.

Both methods will work, but there are some pros and cons to each.

Adding the WiFi interface as a port to your bridge is a simpler method, and it allows you to manage all of your interfaces and VLANs from one place (the Bridge menu). However, this method does not give you as much control over the WiFi interface and its configuration.

Using the Datapath menu to assign the WiFi interface to a bridge and specify a VLAN ID is a more advanced method, and it gives you more control over the WiFi interface and its configuration. This method allows you to configure the WiFi interface as a separate entity from the rest of your interfaces and VLANs, which can be useful in certain scenarios.

Ultimately, the method you choose will depend on your specific requirements and preferences. If you are just starting out with MikroTik and want a simpler configuration, then adding the WiFi interface as a port to your bridge may be the best choice. If you are more experienced and want more control over your WiFi configuration, then using the Datapath menu may be the way to go.

As for your observation about the lack of information on Wave2 configuration, it's true that there isn't as much documentation available as there is for some other topics. However, the MikroTik forums and community are a great resource for getting help and advice on specific issues, so don't hesitate to ask for assistance there if you run into any difficulties.

I managed to set up everything with VLANs configured in Interfaces on both controller and AP. Setting VLAN in Datapath doesn’t work for some reason. Wave2 is really hard to learn indeed.

Capsman and vlan stuff is not yet working as it should be in wifiwave2.
Work In Progress.

I would say wireless in general is rather unstable. Some iPhones had to be reset to connect to hap ax2 and one Samsung TV refused to connect using password and I was able to connect only by WPS button. However some minutes later after I disabled WPS functionality it dropped out of network. Returned to Asus for now. Rock solid wireless is much more important for me now than myriads of almost useless settings.

Following up on this discussion here, I'm trying to understand the differences


I had things set up with VLAN ID on the bridge port, and I had set frame type to `admit-only-untagged-and-priority-tagged` for security

However, then I tried to set the VLAN ID in Datapath, that stopped working and I had to revert to setting the VLAN ID on the bridge port and frame type to `admit all` for things to work again.

Does that make any sense? I thought it was the same config but in a different location. Why did I need to remove the `admit-only-untagged-and-priority-tagged` on the bridge port, while keeping the VLAN ID there?

I was getting very poor WiFi throughput and that seemed resolved when using DataPath, which I also do not understand. Is there any reason why Datapath would be more efficient than the 'legacy' way to configuring VLANs?

Following up on this discussion here, I'm trying to understand the differences


I had things set up with VLAN ID on the bridge port, and I had set frame type to `admit-only-untagged-and-priority-tagged` for security

However, then I tried to set the VLAN ID in Datapath, that stopped working and I had to revert to setting the VLAN ID on the bridge port and frame type to `admit all` for things to work again.

Does that make any sense? I thought it was the same config but in a different location. Why did I need to remove the `admit-only-untagged-and-priority-tagged` on the bridge port, while keeping the VLAN ID there?

I was getting very poor WiFi throughput and that seemed resolved when using DataPath, which I also do not understand. Is there any reason why Datapath would be more efficient than the 'legacy' way to configuring VLANs?

Hmm I am also having issues with wifiwave2 capsman and caps. Did you in the end set vlan-id for datapath, is it actually using the vlan for wifi clients then if you have set vlanid for bridge port and not in datapath?

I had things set up with VLAN ID on the bridge port, and I had set frame type to `admit-only-untagged-and-priority-tagged` for security

However, then I tried to set the VLAN ID in Datapath, that stopped working and I had to revert to setting the VLAN ID on the bridge port and frame type to `admit all` for things to work again.

Does that make any sense? I thought it was the same config but in a different location. Why did I need to remove the `admit-only-untagged-and-priority-tagged` on the bridge port, while keeping the VLAN ID there?

There has been a discussion in the v7.12rc release announcement thread about a strange behavior with Wi-Fi interfaces that are added dynamically via CAPsMAN. The issue is that Wi-Fi interfaces added via CAPsMAN to a specific VLAN appear in the bridge configuration in the list of currently tagged interfaces rather than untagged.

One posting in that thread mentioned a feature where the VLAN membership can be set on a per-client basis and not just a per-interface basis. I assume that this is configured via a user authentication mechanism such as RADUIS.

I am going to make a wild guess as to what is going on here. If Wi-Fi allows different clients using the same Wi-Fi interface to operate on different VLANs, then the software driver for that Wi-Fi interface is effectively performing a bridging/switching function and it is passing traffic for multiple VLANs to and from the actual bridge element. In effect, the interface between the Wi-Fi driver and the bridge is behaving like a "trunk" link rather than like an access port. To do this, it likely needs to utilize VLAN tags so that the multiple data streams (VLANs) can be handled by the bridge and the Wi-Fi driver, but not include the VLAN tags on the packets that are sent over the air.

If so, then when the Wi-Fi driver is operating in a configuration where there is some aspect of dynamic configuration of its VLAN ID or it supports multiple VLANS, its interface to the bridge would need to operate as a "trunk" with VLAN tags. That would explain why your bridge configuration needs to accept tagged packets and why the v7.12rc release thread is reporting that dynamically added Wi-Fi interfaces appear as tagged and not untagged.

Again, this is all an educated guess, but it seems to explain several unexpected behaviors. I would love to hear someone from MikroTik comment on this or explain the Wi-Fi VLAN behavior in more detail. I currently use the bridge.ports method to configure VLANs for Wi-Fi so that I can have private and guest SSIDs, but I am considering changing to use CAPsMAN and the wifiwave2.datapath method. If you are not using CAPsMAN or per-client VLAN membership, then it is probably better to keep all of the VLAN configuration under the bridge configuration.

i have found 2 ways that vlans are working in wave2

1.
- Add the wlan interface as a bridge port with vlan ID 1 and admit only vlan tags data (trunk port).
- In bridge >>vlans add the wifi interface as tagged along with the bridge.
- In wireless >> datapath assign as bridge the bridge and vlan the vlan id you want.

2.
- - Add the wlan interface as a bridge port with vlan ID the vlan ID you want and admit only untagged data (access port).
- - In bridge >>vlans add the wifi interface as UNtagged.
- - Do nothing in wireless >> datapath.

I dont know which one is correct or not, i am following the 1st way.

I used to apply 2nd way.
Much cleaner since you do not need to fiddle with datapath.

However ... when using capsman, datapath may be used for vlan assignment of wifi interfaces on caps devices.
And since local wifi interfaces are not controlled through capsman and need to be configured as local interfaces, it may be needed to do it anyhow if you want to remain consistent with config.

Check out 7.12 and then please comment HOELVE

There should be three courses of action on any VLAN setup to be consistent,

a. WIFIWAV2 setup when CAPSMAN is on local device
b. WIFIWAV2 setup when CAPSMAN is not local, ( aka not capsman controller on this device )
c. WIFIWAV2 setup WITHOUT capsman ( like normal vlan bridge filtering )

I know C - its one SETUP aka pcunite.
I dont know A or B. ( each should have ONE solution )

*) wifiwave2 - added an alternative QoS priority assignment mechanism based on IP DSCP;
*) wifiwave2 - added comment property for registration-table;
*) wifiwave2 - added station-bridge interface mode;
*) wifiwave2 - correctly add interface to specified "datapath.interface-list";
*) wifiwave2 - do not show default "l2mtu" on compact export;
*) wifiwave2 - enable changing interface MTU and L2MTU;
*) wifiwave2 - fixed malformed Interworking packet elements;
*) wifiwave2 - fixed PTK renewal for interfaces in station mode;
*) wifiwave2 - fixed re-connection failures for 802.11ax interfaces in station mode;
*) wifiwave2 - fixed sniffer command not receiving any QoS null function frames when using 802.11ax radios;
*) wifiwave2 - fixed untagged VLAN 1 entry when using "vlan-id" setting together with vlan-filtering bridge;
*) wifiwave2 - fixed warning on CAP devices when radar detected;
*) wifiwave2 - implemented an option to transmit IP multicast packets as unicasts;
*) wifiwave2 - improved compliance with regulatory requirements;
*) wifiwave2 - limit L2MTU to 1560 until a fix is available for a bug causing interfaces to fail transmitting larger frames than that;
*) wifiwave2 - list APs with a higher maximum data rate as more preferable roaming candidates;
*) wifiwave2 - log more information regarding authentication failures;
*) wifiwave2 - make 4-way handshake procedure more robust when acting as supplicant (client);
*) wifiwave2 - use CAPsMAN's "datapath.vlan-id" on CAP for bridge port "pvid";

I have just switched to 7.13 and it seems it's that the only way to make it working is to let the device add CAP locally with datapath. If you don't let the device to be added locally it won't be added remontly on CAPS server anyway, and your CAP will not work properly.