When setting the Capsman config for my aps (in data path on cpasman) to make traffic process to on-Capsman
The AP’s stop broadcasting there SSID and error for all AP’s result in saying data channel not supported.
Capsman operates perfectly fine otherwise.
I’ve run this in V6 with no hassles and no hassles in V7.13.4
Is this a bug or is there something I am missing with the new version 7.19.3?
see:
thanks for the info much appreciated
I've stumbled on the same issue, so I just would like to check whether there are any concrete plans this to be introduced in future RouterOS versions? Currently I'm using Chateau PRO ax together with wAP ax to cover both levels on the new apartment we moved in, I'm running version 7.19.4 now and capsman traffic processing is still not available. Currently this is the only issue that stops me from fully upgrading my existing networks at my mother and brother's houses. I need this feature, because I have found that this is the easiest and the most convenient way of using DLNA from my brother's NAS to stream video on the TV sets.
i would like to know too as i have mulple sites with hundreds of APS on 7.14 that still work fine, using the traffic processing on Capsman and not sure why this feature was pulled/broken so abruptly.
The question is, how do you do client isolation with local forwarding... because from what I understand the magic button "client isolation" will only work to traffic that passes through the device that manages capsman and not to "local forwarded traffic" like 2 clients connected to the same access point and on the same band.
With local forwarding, client isolation works between clients which are connected to same radio (if AP has two radios, e.g. 2.4GHz and 5GHz, then client isolation works between clients on same radio and not between clients connected to different radios). And that's the same as when CAPsMAN is not even used (it's a datapath property and non-CAPsMAN provisioned WiFi interfaces needs datapath settings as well).
To isolate clients on different radios, one can use bridge horizon (or similar functionality) to block traffic between different radios and APs. The nuisance is that it has to be done on all network gear in LAN (each AP, each switch including router if it has multiple LAN ports) and can be very nasty job if LAN infrastructure is shared for different VLANs.
It would be possible to use different VLANs for each radio (which beats the CAPsMAN generalized provisioning rules to certain extent), bring those VLANs on a router (can be central router or CAPsMAN device) and merge them together (to keep station mobility) on a bridge with horizon set ... but such bridge would be entirely software and extremely ugly thing. OTOH CAPsMAN forwarding is entirely software as well, so nothing is lost on that front.
Would this also block clients between different APs?
I can understand that in order to isolate clients of the Same Access Point, I need to essentially prevent forwarding between local wifi interfaces.
What about two clients that are on different access points? Assuming typical scenario of single switch where we have our router on-a-stick/Capsman and our access points connected, I would assume port isolation needed on switch between access point ports so that traffic passes through router/capsman.
I am not familiar how bridge horizon works, I will read up to check it. Thank you for pointing it out.
The same principle applies. When there are two radios in same AP, both wifiX interfaces are made member of same bridge (and bridge acts like a switch). Bridge horizon (when set) blocks traffic between bridge ports with same horizon value but allows traffic between the rest of ports. Which means you'd have to set on both wifiX bridge ports same horizon value ... and that would make bridge block all traffic between both wifi radios.
If you have multiple APs, connected to same (Mikrotik) switch, then you could similarly configure bridge horizon values for switch ports connecting APs (on certain switch models one would have to look into switch chip configuration to do the same in order to keep hardware offload).
The problem arises when you have mixed traffic: e.g. if you use ethernet port on AP to connect wired device but you want to allow wired device to communicate with other devices without limits you want to impose on wireless clients. In such case, traffic from such "mixed mode" AP would arrive to switch port mixed (wireless stations and wired client) and switch has no way of identifying to which device certain frame belongs and where it's allowed to go. In this case using VLANs help (switches are good in doing VLANs) and wired client's traffic is easily recognized and handled accordingly. And similarly on a router-on-a-stick you need some way to differentiate between traffic of different APs in order to block traffic between different APs. And without capsman-forwarding, IMO VLANs are the only way.
After upgrading to version 7.19.6 a couple of days ago, still I'm not able to use CAPsMAN processing for my wAP ax which as far as I know uses Qualcom chips. Does anybody have an idea when this would be finally available? Shouldn't Mikrotik aim for at least feature parity with version 6?
Ideally yes but with wireless drivers they were dealing with in-house developed material. They could pretty much do with it what they wanted.
Wave2 drivers are vendor material and then flexibility is a lot less.
It has been already mentioned a properly created VLAN setup will take care of this.
Everything VLAN, also management plane, all traffic without exception going to capsman controller and only there apply breakout as needed to wherever you want.
Please don’t confuse this with the RouterOS version. It has nothing to do with v6. The difference comes from the drivers. The older driver (wireless) is still available in v7 for devices with compatible hardware, and you can use CAPsMAN forwarding just as before. However, newer devices only support the new wifi-qcom driver, which currently offers fewer options. It might support CAPsMAN forwarding in the future, but at the moment it does not. This feature was never removed - it simply has never been part of the new driver.
I understand the issue with the qcom drivers.
What I do not understand is why we're mixing VLANS with CAPWAP tunnels? This is what CAPsMAN uses, right? At least the last time I was sniffing traffic on my machine, there was a CAPWAP tunnel for the management of the AP and a CAPWAP tunnel for the data traffic both of which terminate on the CAPsMAN. I agree that with VLANs traffic isolation could happen, but what if I have a remote AP and I would like to tunnel the traffic to my centrlized CAPsMAN? How this could be achieved with a VLAN?
Regarding CAPsMAN package available in RouterOS v7, I acknowledge, I didn't know that. I'm yet to test this, as so far I haven't done a migration from v6 to v7, I've deployed v7 from scratch on newer devices which support it out of the box and have the newer Wave2 chips.