capsman local bridge as datapath

RouterOS Wireless Networking
1

I’m testing out capsman. What I’m trying to do is to provision multiple ssid to multiple wAP ac / hAP ac that already has vlan and bridges configured. The problem is that provisioning does not add wlan interface to the local bridge at the ap. I have to log into every ap and run something like

/interface bridge port add bridge=bridge-admin interface=wlan2

for every virtual AP that I add to the capsman. Am I missing something from the config?

So all devices has:

/interface vlan
add interface=ether1 name=vlan-admin vlan-id=7
add interface=ether1 name=vlan-gjest vlan-id=24

/interface bridge
add name=bridge-admin
add name=bridge-gjest

/interface bridge port
add bridge=bridge-admin interface=vlan-admin
add bridge=bridge-gjest interface=vlan-gjest

On router running capsman I have:

/caps-man security
add authentication-types=wpa2-psk encryption=aes-ccm group-encryption=aes-ccm \
    group-key-update=5m name=admin passphrase=passAdmin
add authentication-types=wpa2-psk encryption=aes-ccm group-encryption=aes-ccm \
    group-key-update=5m name=gjest passphrase=passGjest
/caps-man configuration
add country=norway datapath=admin datapath.bridge=bridge-admin \
    datapath.local-forwarding=yes mode=ap name=admin security=admin ssid=\
    wlanAdmin
add country=norway datapath=gjest mode=ap name=gjest security=gjest ssid=\
    wlanGjest
/caps-man datapath
add bridge=bridge-admin local-forwarding=yes name=admin
add bridge=bridge-gjest local-forwarding=yes name=gjest
/caps-man manager
set ca-certificate=auto certificate=auto enabled=yes
/caps-man provisioning
add action=create-dynamic-enabled master-configuration=admin name-format=\
    prefix-identity name-prefix=cap slave-configurations=gjest

As bridges has the same names in all devices, I was expecting this to do what I was looking for:

/caps-man datapath
add bridge=bridge-admin local-forwarding=yes name=admin
add bridge=bridge-gjest local-forwarding=yes name=gjest

But apparently it does not. Is there a way to link a ssid to a bridge on each of the AP’s from capsman?

2

In short, add vlan (not wlan) to the local bridge, and add the same vlan to the wlan :wink:

3

Thanks, that was the trick!

I add some details in case someone is searching for the solution to a similar issue.
When using capsman forwarding:
-set bridge in datapath section of capsman

  • do not set bridge in cap config.

When using local forwarding:

  • set vlan using bridge as interface. Do not use individual bridges for each vlan on the cap (you can still use individual bridges on capsman)
  • set bridge in cap config
  • do not set bridge in capsman
  • set vlan=use tag and vlan id in capsman datapath section. And the obvious: enable local forwarding
4

Hello,

I have been looking for this solution for quite some time, finally here is the answer, thanks.
However :slight_smile: I am unable to add PVID to wlan interface added inside the bridge CAP side.
They always end up untagged with PVID 1.

Any idea?

Cheers

5

That should be OK because if the VLAN settings from CAPsMAN datapath configuration really do work even for ****

datapath.local-forwarding=yes

, there should be no tagless packets, so the

pvid

value should never be necessary. Each packet should get tagged already at the (virtual) AP on its way from the air to the wire, and untagged there on its way from the wire to the air.

If it eventually does not work the way above, you have to prevent the automatic addition of CAPsMAN-controlled interfaces to the bridge, and your only currently available way to get to the necessary data to add them using a script (where packets from the wireless interface would come tagless and the ****

pvid

would thus be important) seems to be

/interfface wireless print file=my-wlan-list
{
  local contents=[/file get my-wlan-list.txt]
 ...parse $contents for the information you need...
}
6

OK got it. But it only works if I manually add wlan interfaces into /interface bridge vlan:

add bridge=br0 tagged=br0,ether1-upstream,wlan1,wlan2,wlan3,wlan4,wlan5,wlan6 vlan-ids=100,200,300

wlan[N] have been added manually. Should I expect these interfaces to get into “tagged”?

7

I’m afraid the CAP configuration may not (yet) be aligned with the new bridge implementation, so if you can live without ****

vlan-filtering

on the bridge, setting it to

no

should be your workaround (as in this mode, the configuration in

/interface bridge vlan

is ignored). Or try to split that line into three, each with a single VLAN ID in vlan-ids, and see whether that helps the interfaces to be added there automatically. But since in this case you don’t need to link the particular SSID to a particular interface and VLAN ID, and the interface names can be obtained using a script, it should be possible to add them to the configuration this way.

8

I already tried splitting the entry in three different ones for each vlan.
BTW, would you / anyone know the difference between adding them to a single entry vs multiple ones? Is there any?

9

…and it didn’t work automatically either, yes, I’ve checked yesterday as well.

BTW, would you / anyone know the difference between adding them to a single entry vs multiple ones? Is there any?

I guess that the basic idea is just to simplify the configuration if several VLANs share the same physical topology, so there should be no functional difference between

/interface bridge vlan
add bridge=br1 vlan-ids=11,22 tagged=br1,ether1,ether2

and

/interface bridge vlan
add bridge=br1 vlan-ids=11 tagged=br1,ether1,ether2
add bridge=br1 vlan-ids=22 tagged=br1,ether1,ether2

I haven’t tested with MSTP heavily but even there you have to be able to configure untagged ports for one particular VLAN so a dedicated line for that VLAN is necessary even if that VLAN shares the spanning-tree instance with others.

10

Thank you for your answers sindy, much appreciated.

I ended up creating a scheduled job setting “tagged” interfaces on a regular basis - fixed!

Thank you.

11

Could you please post your script?

12

Hey,
Not sure I still have it cause either it wasn’t required in the first place or RoS evolved enough to tag them correctly (and add them to the bridge mentioned in the caps conf).
Hope this helps otherwise we can go further into the details.

13

I hazily remember this is the case and that it did not take long after we’ve discussed it here.