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
-
-
JohnTRIVOLTA
Member
- Posts: 399
- Joined:
- Location: BG/Sofia
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
it's the same, wireless interfaces are placed manually in the bridge, or with datapath are dynamically joined to the bridge!
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
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.
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
Capsman2 (for wave2 devices) refers to CAP's local bridge in datapath configuration (capsman v2 doesn't (yet?) support capsman forwarding).
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
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.
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
No, CAPs' bridges won't be available in CAPsMAN config.
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
So what’s the purpose of this setting?
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
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 ...
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 ...
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
No, it's not possible. So your advice is to do it via CLI?
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
If you understood my previous post in any other way, then I failed to make my intention clear 
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
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.
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.
Last edited by reygar5 on Fri May 12, 2023 4:51 pm, edited 2 times in total.
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
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.
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
Capsman and vlan stuff is not yet working as it should be in wifiwave2.
Work In Progress.
Work In Progress.
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
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.
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
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?
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?
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
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?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?
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
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.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?
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.
-
-
MrRobotdev
just joined
- Posts: 20
- Joined:
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
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.
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.
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
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.
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.
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
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";
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";
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
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.
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
In my configuration (AX3 as a CAPSMAN, AX2 as a CAP, both using ROS 7.16.1 ) I was able to use datapaths configured on the CAPSMAN to assign VLANs to both local and remote radios.
But I didn't like the fact that with usage of datapath I got a tagged wireless traffic (Torch tool showed VLAN ID on wireless interfaces and listed all wireless interfaces as "tagged").
To switch back to "pvid" vlan setting via I have encountered with error that wireless interfaces were already added as dynamic bridge members.
Removing of "datapath" in didn't help.
So the only way I found to use pvid via /interface/bridge/port instead of previously used "datapath" was:
But I didn't like the fact that with usage of datapath I got a tagged wireless traffic (Torch tool showed VLAN ID on wireless interfaces and
Code: Select all
/interface/bridge/vlan> printTo switch back to "pvid" vlan setting via
Code: Select all
/interface/bridge/portRemoving of "datapath" in
Code: Select all
/interface/wifiSo the only way I found to use pvid via /interface/bridge/port instead of previously used "datapath" was:
May be it will be helpful for someone.1) Disable wireless interface
2) Remove current datapath setting in interface's "Datapath" tab
3) CHANGE BRIDGE to any other in interface's "Datapath" tab
4) Enable interface
5) Return the desired bridge in interface's "Datapath" tab
6) Configure pvid in /interface/bridge/port
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
But I didn't like the fact that with usage of datapath I got a tagged wireless traffic
I wonder why this bothers you?
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
Let’s say I have obsessive-compulsive disorder )I wonder why this bothers you?
My vision of an ideal world (mainly came from years of configuring various Cisco networks) is that user access edge should be always in “access mode”, that is tagged traffic should be avoided at all cost on access ports/networks.
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
And switch to switch should be connected how with your OCD ?
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
LACP Trunk with VLAN filtering )And switch to switch should be connected how with your OCD ?
But in this case we don’t speak about switch. We speak about L2 interface with wireless connection at L1. For me there is no difference in terms of edge security with Ethernet.
With usage of datapath wlan interface starts to operate in a trunk mode: at least torch shows tagged traffic on wlan interfaces themselves.
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
Let’s say I have obsessive-compulsive disorder )I wonder why this bothers you?
My vision of an ideal world (mainly came from years of configuring various Cisco networks) is that user access edge should be always in “access mode”, that is tagged traffic should be avoided at all cost on access ports/networks.
In this sense, wireless radio interface acts as a switch by itself ... e.g. it allows station-station communication without related frames ever exiting wireless driver. Which means that you should treat wireless interface as part of LAN (and can thus carry tagged traffic). Edge is then on the radio side of interface and wireless driver does tagging/untagging as needed. (it can act similarly to MAC-VLAN ... i.e. attaches different VLAN IDs based on MAC address of station).
Another scenario: if one uses a pair of "off the shelf" MT wifi devices, they can be configured to work in PtP mode (one as AP-bridge and other as station-bridge) and they can pass tagged frames end to end ... so they essentially make a trunk connection between both ends.
To me, conceptually edge port is the point where I cease to have control over connected device. Either that's a computer connected to ether port (and I'm not admin of that computer). Or wireless device connected to SSID ... but radio interface of AP is still (hopefully) under my control.
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
In case when I connect AP's as a wireless bridge with trunk - no questions about it. I would put specific wlan interface in "admit all" mode.
But for users WiFi I would like to avoid it.
DATAPATH setting doesn't give me this option: it puts wlan in "admit all", lists this interface in "tagged" and no option to change this behavior.
But for users WiFi I would like to avoid it.
DATAPATH setting doesn't give me this option: it puts wlan in "admit all", lists this interface in "tagged" and no option to change this behavior.
Re: Wave2 - Bridge.Ports vs. Wifi.Datapath
In case when I connect AP's as a wireless bridge with trunk - no questions about it. I would put specific wlan interface in "admit all" mode.
But for users WiFi I would like to avoid it.
Well ... what you'd like in this case doesn't correspond with what you can. And since it's up to personal preference (I explained you how it's properly done in ROS right now) you will have very hard time to persuade MT devs to change it ... even if a portion of users would agree with you (I wouldn't).