CAPsMAN local forwarding not working :-(

UMarcus · Fri Jun 14, 2019 11:19 am

Hello.
I try to get my CAPsMAN configuration running with local forwarding enable, but I still fail.

To show my configuration I prepare a spare device on my desk with minimal configuration for testing.
I think the issue is related to my additional VLAN / bridge configuration.
I want to have the CAP Interface as VLAN tagged traffic (110).
If I disable 'local forwarding' all is working as expected, but if enabled than there is no traffic flow anymore to WLAN clients.

I try different things by playing around with the VLAN options in the bridge/port and datapath but the result is always the same

Could anybody please have a look on my configuration and give me a hint whats wrong ?

/caps-man channel
add frequency=2412 name=channel1
/interface bridge
add name=bridge1 vlan-filtering=yes
/interface wireless
# managed by CAPsMAN
# channel: 2412/20-Ce/gn(20dBm), SSID: test, local forwarding
set [ find default-name=wlan1 ] disabled=no ssid=MikroTik
set [ find default-name=wlan2 ] ssid=MikroTik
/interface vlan
add interface=bridge1 name=vlan1-manage vlan-id=1
add interface=bridge1 name=vlan110-wlan vlan-id=110
/caps-man datapath
add bridge=bridge1 local-forwarding=yes name=datapath1 vlan-id=110 vlan-mode=use-tag
/caps-man security
add authentication-types=wpa2-psk encryption=aes-ccm,tkip name=security1 passphrase=test2019
/caps-man configuration
add channel=channel1 country=germany datapath=datapath1 name=cfg1 security=security1 ssid=test
/caps-man interface
add configuration=cfg1 disabled=no l2mtu=1600 mac-address=6C:3B:6B:xx:xx:xx master-interface=none name=cap1 radio-mac=6C:3B:6B:xx:xx:xx radio-name=6C3B6Bxxxxxx
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/caps-man manager
set enabled=yes
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=ether5
add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=vlan110-wlan pvid=110
/interface bridge vlan
add bridge=bridge1 tagged=bridge1 untagged=ether2 vlan-ids=1
add bridge=bridge1 tagged=bridge1,ether5 vlan-ids=110
/interface wireless cap
# 
set caps-man-addresses=192.168.11.127 enabled=yes interfaces=wlan1
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=vlan110-wlan

Thanks in advance,
best regards
Marcus

mkx · Fri Jun 14, 2019 11:52 am

After wireless is up, what do the following commands show?

/interface wireless print detail
/interface bridge port print detail where interface=wlan1
/interface bridge vlan print detail

I don't know what should the output of the third command look like. My setup uses VLANs set up on switch chip and even if my capsMan managed wireless interface with local-forwarding enabled is configured with "vlan-mode=use-tag vlan-id=110", bridge itself is acting as a dumb switch without vlan config. In your case I would expect to see wlan1 interface as tagged member of bridge with vlan-ids=110 ...

I don't think this setting is correct:

/interface bridge port
add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=vlan110-wlan pvid=110

Actually it shouldn't be there at all as vlan110-wlan is a VLAN interface of the very same bridge ...

UMarcus · Fri Jun 14, 2019 12:38 pm

You are right ! Now it is working. Many thanks for the hint.

So I removed the VLAN110 interface from the bridge and add the WLAN1 to the bridge ! It seems that I always forgot to add the wlan1 to the bridge interface while playing around with the settings (stupid user

)

Now I get following output :

[admin@MikroTik] > /interface wireless print detail                         
Flags: X - disabled, R - running 
 0  R ;;; managed by CAPsMAN
      ;;; channel: 2412/20-Ce/gn(20dBm), SSID: test, local forwarding
      name="wlan1" mtu=1500 l2mtu=1600 mac-address=6C:3B:6B:xx:xx:xx arp=enabled interface-type=Atheros AR9300 mode=station ssid="MikroTik" frequency=2412 band=2ghz-b/g channel-width=20mhz secondary-channel="" 
      scan-list=default wireless-protocol=any vlan-mode=no-tag vlan-id=1 wds-mode=disabled wds-default-bridge=none wds-ignore-ssid=no bridge-mode=enabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 
      default-client-tx-limit=0 hide-ssid=no security-profile=default compression=no 

 1 X  name="wlan2" mtu=1500 l2mtu=1600 mac-address=6C:3B:6B:xx:xx:xx arp=enabled interface-type=Atheros AR9888 mode=station ssid="MikroTik" frequency=5180 band=5ghz-a channel-width=20mhz secondary-channel="" scan-list=default 
      wireless-protocol=any vlan-mode=no-tag vlan-id=1 wds-mode=disabled wds-default-bridge=none wds-ignore-ssid=no bridge-mode=enabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 
      default-client-tx-limit=0 hide-ssid=no security-profile=default compression=no 
[admin@MikroTik] > /interface bridge vlan print detail                      
Flags: X - disabled, D - dynamic 
 0   bridge=bridge1 vlan-ids=1 tagged=bridge1 untagged=ether2 current-tagged=bridge1 current-untagged=ether2,wlan1 

 1   bridge=bridge1 vlan-ids=110 tagged=bridge1,ether5,wlan1 untagged="" current-tagged=bridge1,ether5,wlan1 current-untagged="" 
[admin@MikroTik] > /interface bridge port print detail where interface=wlan1
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 0     interface=wlan1 bridge=bridge1 priority=0x80 path-cost=10 internal-path-cost=10 edge=auto point-to-point=auto learn=auto horizon=none auto-isolate=no restricted-role=no restricted-tcn=no pvid=1 frame-types=admit-all 
       ingress-filtering=no unknown-unicast-flood=yes unknown-multicast-flood=yes broadcast-flood=yes tag-stacking=no bpdu-guard=no trusted=no multicast-router=temporary-query fast-leave=no

With following configuration :

/caps-man channel
add frequency=2412 name=channel1
/interface bridge
add name=bridge1 vlan-filtering=yes
/interface wireless
# managed by CAPsMAN
# channel: 2412/20-Ce/gn(20dBm), SSID: test, local forwarding
set [ find default-name=wlan1 ] disabled=no ssid=MikroTik
set [ find default-name=wlan2 ] ssid=MikroTik
/interface vlan
add interface=bridge1 name=vlan1-manage vlan-id=1
add interface=bridge1 name=vlan110-wlan vlan-id=110
/caps-man datapath
add bridge=bridge1 local-forwarding=yes name=datapath1 vlan-id=110 vlan-mode=use-tag
/caps-man security
add authentication-types=wpa2-psk encryption=aes-ccm,tkip name=security1 passphrase=test2019
/caps-man configuration
add channel=channel1 country=germany datapath=datapath1 name=cfg1 security=security1 ssid=test
/caps-man interface
add configuration=cfg1 disabled=no l2mtu=1600 mac-address=6C:3B:6B:xx:xx:xx master-interface=none name=cap1 radio-mac=6C:3B:6B:xx:xx:xx radio-name=6C3B6Bxxxxxx
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/caps-man manager
set enabled=yes
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=ether5
add bridge=bridge1 interface=wlan1
/interface bridge vlan
add bridge=bridge1 tagged=bridge1 untagged=ether2 vlan-ids=1
add bridge=bridge1 tagged=bridge1,ether5,wlan1 vlan-ids=110
/interface wireless cap
# 
set caps-man-addresses=192.168.11.127 enabled=yes interfaces=wlan1
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=vlan110-wlan

Many thanks for your fast and kind support. I appreciate that very much.

Regards
Marcus

mkx · Fri Jun 14, 2019 1:55 pm

So I ... add the WLAN1 to the bridge !

This doesn't seem to hurt but it seems it's not necessary ... I've had wlan1 interface added to bridge as well. However, when I was looking around while preparing my previous answer, I set /interface wireless cap set enabled=no, removed wlan1 interface from bridge and set /interface wireless cap set enabled=yes ... an the wlan1 interface got added to the bridge automatically (it has "Dynamic" flag set in /interface bridge port print). I guess to have it working one has to set the correct bridge in /interface wireless cap settings.

UMarcus · Sat Jun 15, 2019 12:14 pm

So I ... add the WLAN1 to the bridge !
This doesn't seem to hurt but it seems it's not necessary ... I've had wlan1 interface added to bridge as well. However, when I was looking around while preparing my previous answer, I set /interface wireless cap set enabled=no, removed wlan1 interface from bridge and set /interface wireless cap set enabled=yes ... an the wlan1 interface got added to the bridge automatically (it has "Dynamic" flag set in /interface bridge port print). I guess to have it working one has to set the correct bridge in /interface wireless cap settings.

Hmm. Okay. I never had this seen that the wlan interfaces are dynamically added while playing around. I always observe the 'current tagged' entries because I thought these need to be the key to get it working. Anyhow now it is working.
I also read the documentation about VLAN via switch chip and it turns out that only new devices are able to do hardware offload if VLAN filtering enabled in the bridge. So i decide to go back to the switch menu and configure the VLAN filtering to enable hardware offload. This was clearly indicated by the 'H' flag which are displayed as I disable VLAN filtering in the bridge.

Thx Marcus

mkx · Sat Jun 15, 2019 12:42 pm

I'm glad it's working for you now.

I'll just bitch about it a little more, I like discussing things I don't know much about

I also read the documentation about VLAN via switch chip and it turns out that only new devices are able to do hardware offload if VLAN filtering enabled in the bridge.

There are two ways of configuring VLANs: old way on ROS <=6.40 and new way on ROS >=6.41. In old times bridge was not VLAN -aware and it was necessary to configure things via /interface ethernet switch (if it exists), by configuring VLANs on interfaces directky (if that was supported) or by using multiple bridges and vlan interfaces (for physical or PtP interfaces which didn't support VLAN configurations). And "vlan-mode=... vlan-id=..." on wlan interface is a remnant from old times.
This way is still available. And can be used to offload switching (with VLAN filtering enabled) to switch chip if it decently supports VLANs (unfortunately a few newest RB devices feature shitty switch chip).

The new way is to configure everything on bridge. Only a few devices can offload this to hardware (CRS3xx in particular). The new way of dealing with VLANs on wlan is to omit VLAN settings on wlan interface, but include them on bridge port. The way capsMan does it is a bit moot to me, it doesn't seem to do it entirely the new way, more like the old way (at least that's how it's done on my "old school" cap device).

UMarcus · Sat Jun 15, 2019 1:36 pm

Again many thanks for your explanation.

For me it is confusing to have multiple option to do the same thing. I love the approach to do all in the bridge configuration as this is from my perspective the most intuitive way. Also the 'current tagged / untagged' list helps to confirm correct configuration.
But as I want to have the best performance without CPU load i have to go back to the switch menu.

mkx · Sat Jun 15, 2019 2:15 pm

But as I want to have the best performance without CPU load i have to go back to the switch menu.

Personnaly I don't care about CPU load too much. I mean: why should CPU load be kept to say below 10% most of the time, specially if there isn't a single task which might be bound to single CPU core hitting the ceiling?

There's a bigger issue with bridge forwarding (compared to switch chip forwarding), at least on most of modern devices with fast CPUs (such as hEX, hAP ac2 or RB4011): the interconnection between switch chip and CPU might become a bottleneck (e.g. if a 5-port Gbps switch has only 1Gbps interconnection to CPU .. even a 2.5 Gbps interconnection might be a bottleneck from time to time).

And then there are devices with decent switch chips (e.g. hAP ac2), but might have some bug lurking around (e.g. aforementioned hAP ac2), which might force user to stick to "everything on bridge" concept ...

UMarcus · Sat Jun 15, 2019 5:59 pm

You are absolutely right. Limit bandwidth to CPU is the bigger issue.

What about the bug on hap ac2 ! I use three of them in my network. But I never face issues with switch traffic on that devices ?

mkx · Sat Jun 15, 2019 9:08 pm

MT support acknowledged a bug about untagging certain PPPoE packet ... which means PPPoE doesn't work in the following scenario: ISP provides PPPoE over untagged ethernet, which is connected to access port of a VLAN. Somewhere there's vlan interface and PPPoE client is attached to it. As mentioned it doesn't work if it's hAP ac2 switch chip tagging/untagging the traffic. Things work if it's hAP ac2 CPU doing the tagging and untagging (bridge vlan-filtering) or some other device (e.g. RB951G or a smart switch, both connect to hAP ac2 over vlan trunk port).

I also had big stability issues (another forum member reported similar experience) when VLANs were handled by hAP ac2 switch chip ... ethernet would lock up and reboot was the only cure ... watchdog (pinging directly attached smart switch) did reboot device 2 to 10 times a day.

After I reconfigured my hAP ac2 to bridge vlan-filtering and upgraded to 6.44, everything works rock solid. I can't say which made things stable. I didn't bother to check if the bug affecting PPPoE is still present, I guess it is (when MT support acknowledged the bug, they said they didn't have ETA for the fix) as no change log mentioned anything about it ever since.

UMarcus · Sun Jun 16, 2019 12:35 pm

Thank you for the Information. Good to know.

I never use PPoE with my MT Devices as my ISP provide cable network (DOCSIS).

As mentioned until now I never face any issues with VLAN Switch on HAP AC2. May be because I use them mainly as CAP and rarely as switch in some edge cases.

Regards
Marcus

UMarcus · Sun Jun 16, 2019 8:11 pm

After two day's with local forwarding I get the impression that WLAN roaming between the cap's is more stuck and sometimes with complete interrupt of WLAN signal

May I go back to CAPsMAN forwarding to cross check this observation. If it turns out that WLAN roaming with CAPsMAN forwarding is better working I will go back to previous configuration.

CAPsMAN local forwarding not working :-( [SOLVED]

CAPsMAN local forwarding not working :-(

Re: CAPsMAN local forwarding not working :-( [SOLVED]

Re: CAPsMAN local forwarding not working :-(

Re: CAPsMAN local forwarding not working :-(

Re: CAPsMAN local forwarding not working :-(

Re: CAPsMAN local forwarding not working :-(

Re: CAPsMAN local forwarding not working :-(

Re: CAPsMAN local forwarding not working :-(

Re: CAPsMAN local forwarding not working :-(

Re: CAPsMAN local forwarding not working :-(

Re: CAPsMAN local forwarding not working :-(

Re: CAPsMAN local forwarding not working :-(