Why can't wireless and wifi-qcom co-exit?

Remind me what's the technical reason why the classic wireless package can't co-exist (enabled at same time) with wifi-qcom on a AX router?

I notice the release of wAP ax LTE7. Friends currently use a wAP ac LTE6 on their holiday home on the outside and supplies Wi-Fi to the garden. They then have four cAP ac access points in the house controlled by CAPsMAN. If they upgraded, they'd loose CAPsMAN on the legacy devices. They're quite happy with the existing set-up but always keep an eye on upgrades.

The 2 capsman CAN coexist with v7.13+
But configs will be separate. (This is because capsman "kind of" forwards the hardware to the controller which then takes over controll of the card and qcom drivers and mikrotik drivers are working differently)

From what I heard you just can't have wireless package installed on the AX line if you want the wifi to work (but I'm not sure if I remember correctly)

But you might also be able to run wifi-qcom-ac on all those APs as long as it's an ARM wap ac.

Sorry I should have clarified that I know you can have the two CAPsMAN running but the wireless on the router itself is disabled. Which would be a problem in this use case.

It seems that technical reason (at least was in times when AC devices were the flag ship devices) is that both drivers don't behave nicely ... meaning that each will try to drive any wireless chip present even though it's not compatible. And then the second driver loaded can't work with same wireless chip because the driver loaded first will still seize it. This reason can't be true for AX (and BE) devices as legacy wireless drivers don't support the new wireless chips so this race condition should not exist in new devices.

IMO the issue would be solvable if MT cared to put some developers' effort into it. But since the issue is a transitional one (only exists for AC devices) the didn't bother.
In your particular case the issue is a bit less transitional because you only want to run legacy CAPsMAN on your AX device and this scenario might exist a bit longer ... and also this issue might be solvable (by MT's devs) if they decided to split legacy CAPsMAN from legacy wireless ... but I guess they won't bother with this either.

I second suggestion by @itimo01 to upgrade/install wifi-qcom-ac on those cAP ac APs. It's almost (but not entirely) sure that they will perform better than they are running legacy wireless driver. And the new CAPsMAN, so no need for legacy wireless package on capsman device.

Oh that completely changes things!

If your capsman device (you didnt mention which one :stuck_out_tongue: ) already has ROS 7.13 or higher installed then you WONT lose the wireless card because you dount need to install the wifi package :slight_smile:

Wifi capsman is included in the "Base" RouterOS Package while wireless capsman is only included in the wireless package.

But AFAIK, CAPsMAN is purely a software system and the drivers shouldn't be connected with it. As you say, it could have been a lack of resources or interest. As a one-time low-level software developer (8-bit/16-bit games), I can appreciate that maintaining compatibility with legacy hardware is a huge resource draw and a complex task. That said, this one does jar more than others as it blocks upgrade of the router if one happens to need Wi-Fi on that device as well - which is often the case with LTE devices.

That said, this case is a small installation and we could either drop CAPsMAN entirely and program each cAP ac manually. Or put CAPsMAN on one of the cAP ac. Not helped by it been in a different country. Can't just jump in my car to help.

That was (a political?) decision taken by MT when they split wireless package from core ROS package during transition between ROS 7.12 and 7.13 ... to include legacy CAPsMAN in package with legacy wireless driver. Which makes core ROS package a bit less burdened with legacy stuff (people not running legacy wireless devices won't have legacy CAPsMAN installed).
They could have actually create two optional packages: wireless (with drivers) and wireless-capsman (with only legacy capsman) ... which would allow for flexibility of installing only package required. But MT staff were arguing that each package comes with (non-trivial) space overhead and having many small packages instead of few larger ones would make problem with tight storage (on 16MB ARM devices) even more serious. They wouldn't listen to arguments saying that wouldn't be the case for many users.

There, I fixed it for you :wink::

They wouldn't listen to arguments.

:rofl:

Ahh yes... I've decommissioned a few hAP ac lite devices because of lack of storage. But the cAP ac are okay I think update wise. So far at least.