Wireless vs wifi-qcom-ac for cAP-ac and cAP-acXL

RouterOS Wireless Networking
1

I recently though a lot about wireless vs wifi-qcom-ac.

I now have for about 1 year my cAP-ac’s all running with wifi-qcom-ac. The issue that I manually have to configure the vlans on each AP is annyoing but I can live with that because I have <10 ap’s running. Nevertheless it makes the centrally managed wifi a little bit useless.

But I still think about going back to wireless drivers, because in the past they also worked very well, are less resource intenstive and provide centrally managed vlan configuration, but lack some features including WPA3.

What do you think and what would you do? What’s the recommandation from MikroTik?

At first I thought they are more actively developed than the wireless driver, but for the -ac drivers there were only few changes and bug fixes in the recent ROS upgrades.

The following tables are my person pros for both variants:

wifi-qcom-ac:

  1. WPA3
  2. 802.11r/k/v

wireless:

  1. Less resource intensive
  2. Central management (fully implemented) for VLANs
2

In the past, MT stated that "ac devices came with wireless driver from factory". Which probably tells a lot about MT's commitment to wifi-qcom-ac (which is: not a lot).

So basically you have 3 options when dealing with ac devices, the order below is completely random and everybody has their own criteria to sort the list for their situation and use case.

  1. keep using wireless driver
    This is what these devices came with, is pretty feature-complete apart from newest features, such as WPA-3, mobility and some speed.
  2. use wifi-qcom-ac drivers
    Yes, they do take away quite a few features but not everybody needs them. And for a few there are workarounds (e.g. VLANs). But it also comes with support for new features (WPA-3, mobility and much beter top speeds).
  3. ditch the AC hardware and go with modern devices (either AX now or wait for BE). This likely means more future proof setup as many of AC devices come with too small storage space (which can be a limitation even when using legacy wireless drivers, ROS v7 is larger than v6 even when using wireless, not to mention desire/possibility to run containers ... even if container images are stored on external storage, one still has to install additional package which uses internal storage).

Personally, I went with wifi-qcom-ac ... but I have a single device (Audience) which requires manual VLAN setup. The rest are AX devices and using wifi-qcom-ac enabled me to integrate Audience with common CAPsMAN.
And I love the possibility not to install any optional package on CAPsMAN device which makes my hAP ac2 (used as router and CAPsMAN) a very happy device.

3 
maybe it's worth waiting
7.21beta2
*) wifi - added CAPsMAN forwarding support (datapath.traffic-processing=on-capsman);
1 Like
4

@mkx Thanks for your thoughts. I think Variant 3 isn’t a option for me as I currently don’t need the ax performance, and as many cAPs are involved, it would be an expensive upgrade.

So my first decision some days ago was to switch my setup back to wireless driver, but @Ca6ko ‘s comment seems to be interesting. This was a changelog message I was waiting for very long by now. So maybe I just leave my setup as-is and wait for further details in the changeleogs; But it still has to be figured out what that actually means; I think traffic-processing on-capsman is not the direct option I’m waiting for, but if this is implemented, maybe vlans are as well.

5

I'm not holding my breathe regarding capsman-forwarding. There used to be such functionality on legacy CAPsMAN and it proved a performance bottleneck ... even if CAPsMAN device was a beefy one, it still choked wireless performance on even modest APs, let alone on the fastest CAPs (as compared to running with local-forwarding).

Yes, capsman forwarding does allow for better client isolation (when there are multiple CAPs used) so if this is required, then it's a feature to wait for.

6

As I indicated in my previous post, capsman-forwarding doesn't interest me. My thought train regarding fuss about VLANs is that one has to configure VLANs manually once (takes a few minutes to do it per CAP after one learns all the gory details) but the benefits of having better wifi performance are there each and every day ... so IMO manual work is a good investment with plenty of return.

3 Likes
7

So finally I invested some time and updated my vlan configuration on each cAP with a script. I will stick with qcom-ac and watch the current changelogs.

I hope that the vlan tagging support geht's added soon. In my opinion it is even not necessary to tag the traffic directly in the driver (although this would be the best approach regarding performance), but a simple dynamic bridge configuration generated on the cAP would be definitely enough in the first place.

Finally I compared changes in the documentation about WiFi, there were several ones in the last day, that sounds promising.

1 Like
8

I'm not holding my breathe. VLAN-tagging in the driver was never implemented in wifiwave2 (as was wifi-gen driver called when conceived) and was added only to wifi-qcom after split (between wifi-qcom and wifi-qcom-ac). And I guess that both Mikrotik and Qualcomm (it's their driver with a touch of a lipstick) don't see any value in enhancing -ac driver as devices are not contemporary any more (neither are AX devices but Mikrotik lacks BE offering ... so if they have to, they fiddle with AX drivers).