The Interfaces whould be provisioned perfectly.
but the CAP-Interfaces are put not to bridge “bridge2-ext”.
Why?
On the Client-CAP Antennas i have nothing set as datapath, so i whould like to forward the Data to/from CapsMan.
There are the following datapath settings:
local-forwarding -- controls forwarding mode
openflow-switch -- OpenFlow switch to add interface to, as port when enabled
vlan-mode -- VLAN tagging mode specifies if VLAN tag should be assigned to interface (causes all received data to get tagged with VLAN tag and allows interface to only send out data tagged with given tag)
I tried to set the settings as best as I could.
Nevertheless, the new CapsMan is a little poor or, to say the least, immature.
Why not a new CapsMan (even if wifi) that can also operate the old wireless interfaces? Why 2 CapsMan? In the not too distant future there will be a lot more qcom and ax anyway?
Why can’t “datapath”, “horizon” and “forbid-client-communication” be set in CapsMan? These settings have no effect there.
If the CapsMan provisions the Cap antenna, why can’t I freely set the bridge name in the Caps-Man data path (for configuration) so that at least the master or slave interface on the Cap antenna can be installed automatically to place the bridge that was previously created there (the prerequisite is of course that the bridge created on the CAP antenna matches the freely entered name on the CapsMan (datapath). This would also work without a VLAN for VXLAN or VPLS User.
VLAN currently seems to me to be the only way to separate traffic from 2 SSIDs on one (1!) CAP interface?!
I think it should be possible to shift as many settings as possible to the CapsMan, even for slightly more complex setups
All in all, I’m missing instructions for the latest CapsMan at help.mikrotik.com, which shows exactly what is obviously not possible (yet) with the new CapsMan, especially with regard to slave interfaces and several SSIDs on one wifi interface and the datapath restriction (bridge, horizon, …)
Thing is, that you should never use multiple bridge interfaces to separate traffic… and because it’s not working as you imagine it should, you think that it’s broken…
@christian “/capsman” is for legacy wireless. The old capsman. That’s why none of your settings under “/capsman” show/have any effect.
This doc refers to legacy capsman for wireless drivers. You want to provision/control AX devices, so all your configuration is done below “/interface/wifi/”.
Could be it’s due to the fact that capsman forwarding puts quite some burden on both CAP device (which is manegeable by using faster CPU) and CAPsMAN device (less manageable if there’s large number of CAPs involved), reducing CAP wireless performance. The benefits (in certain use cases thex were invaluable) are probably too marginal for MT po put in necessary effort to (re)implement it with wifi drivers.
Back to OPs original question: why are ports not added to bridge? It works for local interfaces but not for caps. On CAP the bridge is always named “bridgeLocal” no matter what and wifi ports are not added (not on CAPsMAN bridge neither on the CAP local bridge).
I’m not sure if I follow you correctly, but they are added just fine… Thing is, that the bridge is always local, you can not access/see bridges on other devices. So if you create a bridge on CAP, it is accesible only from CAP itself, and vice versa. That applies for datapath too, datapath.bridge is local option and only valid for master interfaces.
Even if the docs say
Virtual (‘slave’) interfaces are by default added to the same bridge, if any, as the corresponding master interface. Master interfaces are not by default added to any bridge.
and from “by default” you can say that this behavior can be altered, but it’s not documented (or I wasn’t able to find it).
EDIT:
it’s done by slaves-datapath in /interface/wifi/cap menu.
:EDIT
If you create a bridge on CAP, you can then set datapath.bridge on CAP’s master interface and wifi interfaces are then added to the bridge as dynamic ports. It works fine…
and the other datapath properties? client-isolation? interface-list? These seem to have no effect either.
Mikrotik should describe their CAPsMAN concept in depth. It is not enough to have some basic configuration examples and a description of each cap/CAPsMAN configuration property on its own in docs. Nobody knows how this all plays together. And it is mega frustrating to go through trial and error just to find out how things maybe work.
As for example there are some people who manually trigger provision after a configuration profile change. Yeah, I understand why someone may get this illusion. It is described nowhere that configs are auto-provisioned on change. The whole topic of what works, what not and what wifi CAPsMAN actually covers must be outlined.
And just to correct myself, you must set two things when prepairing CAP for CAPsMAN environment: manager and bridge. Mode defaults to AP, so it can be omitted.
If we look at “Reset to CAPS mode”
:local brName "bridgeLocal";
:if ($usingWifiPack) do={
:local addDatapath [:parse "/interface $wirelessMenu datapath
add comment=\"defconf\" name=capdp disabled=no bridge=$brName"]
[$addDatapath]
}
if ($usingWifiPack) do={
:set setCap [:parse ":foreach i in=[/interface $wirelessMenu find] do={
/interface $wirelessMenu set \$i configuration.manager=capsman datapath=capdp
}
/interface $wirelessMenu cap
set enabled=yes discovery-interfaces=$brName slaves-datapath=capdp"]
}
It’s exactly what they do, with just small difference. They are creating datapath configuration profile with single setting: datapath.bridge and then appling this profile to interfaces, instead of applying datapath.bridge directly to interface, but the outcome is same.
And I think that they are using “bridgeLocal” to point out, that it exists solely on the CAP itself.
Well, then set “datapath.bridge = bridge” as well. and then show me your winbox window again. On CLI it prints for me, the cap-wifi3 is “datapath.bridge=bridge”. And we all know, this version of CAPsMAN has no local forwarding. So what the heck is it doing?
