recently I set up a capsman on my router (rb750) and combined it with couple of cap acs (all using wifi-qcom-ac-7.14.3-arm.npk) so I can say I know how to do a basic capsman setup.
Now I decided to take my LTE12 router and try to set up a local capsman to manage its two wifi radios. I updated routeros/firmware to most recent (7.14.3) versions, removed wireless package and installed wifi-qcom-ac, reset it once more and tried to enable a local capsman to manage local wifi. Idea is to add cap-acs later after this thing starts working. However, when I enable cap, nothing happens with wifi interfaces. Usual case (with cap-ac) is that at that point they would became managed by capsman, but with LTE12 nothing happens.
Here’s my order of operations:
I create security profile and configuration
in wifi tab under CAP I enable it, set discovery interfaces to all (for now), set capsman address to 127.0.0.1
in remote CAP tab under capsman I enable it, set interfaces to all and my capsman server appears in the list
I also enable provisioning with “create dynamic enable” action and assign a cfg1 configuration
Nothing happens so I reboot, but afterwards also nothing happens. I tried manually disabling/enabling wifi interfaces, but still nothing.
Interesting, can you point me to docs saying that as in official Mikrotik’s YT video guy was doing exactly that? Admittedly, with previous version of capsman, but still, fundamentally there shouldn’t be such a difference.
Also, if managing local interfaces by a locally running capsman isn’t possible, how are we expected to utilise capsman backed roaming (fast transitions)?
This doesn’t seem to do what it’s supposed to do (maybe). It did work in a sense that provision command didn’t complain. My wifi interfaces got “read only”, wifi network specified in configuration appeared, but without internet access. Also I didn’t get a red comment in wifi interfaces about interfaces being managed by capsman.
Just for test, I took one cAP ac and connected it to router - everything worked immediately - I got two cap-wifis in the list of interfaces, bot marked as managed by capsman, I was able to conect to wifi and got internet access immediately.
It seems to me that provisioning you mentioned doesn’t manifest itself in a same way as provisioning of external ap.
Maybe you did not configure “datapath.bridge” to your default bridge (e.g. datapath.bridge=bridge). So your local radios may got provisioned perfectly, but not assigned to any bridge. Would at least explain what you’ve described by “but without internet access”.
Also I didn’t get a red comment in wifi interfaces about interfaces being managed by capsman.
Because - IMHO - they aren’t. They are just provisioned by the same config you specified in provisioning. They are dynamic and when you change your config, it affects your caps and local radios at the same time.
Sorry, I don’t know with this level of details. Maybe the information is outdated. But when I configured my devices I was not able to configure my capsman controller as a cap too. I tried also the route of provisioning the local wifi interfaces, but I cannot see any advantage over applying the configuration profiles.
In the YT Mikrotik videos I watched about capsman and FT they apply the configuration profiles to the local wifi interfaces and manage using capsman only the remote CAPs.
Better documentation often means less complaints (albeit not proportionally) and less support tickets (albeit not proportionally).
Finding the sweet spot among the resources allocated to improving documentation, to support the users, to develop/fix software is crucial.
