Hi, i'm using CAPsMAN to manage remote CAPs.

the issue i am facing is that if the link goes down , for whatever reason, the remote CAPs stop broadcasting.

i tried choosing "local forwarding" mode, and it still stops broadcasting.

is there a way to keep the CAPs running with the provisioned configuration, when the CAPsMAN is uncontactable, at least for an extended duration if we are to remove/replace the CAPsMAN device due to repairs or link down or whatever.

Let me know!! thanks!

I think this is "working as intended"

And it makes sense. You want to use CAPSMAN as a centralised place to provision your APs, including access lists and so on.
You don't want a stray access point to keep working even when it can't contact CAPSMAN.

Imagine an AP goes down. You don't notice. Then you apply a series of ACL and policies... and the AP still keeps working without the new policies. Wouldn't be a good thing, would it?


On the other side I understand perfectly your anger

Hi, i understand where you are coming from.

i suppose if traffic is CAPsMAN forwarded, it would make sense to have all APs bring down the SSID if it couldn't contact CAPsMAN

but what if the SSID is local forwarded? without the need of packets traversing the CAPsMAN, wouldn't it be a good idea to have the SSIDs continue broadcasting, at least for a configurable period of time, before the CAP decides that it's too long a disconnection from the CAPsMAN and disables the SSID.

i think it would be a good feature to have. especially if your CAPsMAN is in the headquarters, and there's dozens of remote sites you would like to manage , but not forwarding all traffic back to the CAPsMAN. Links can go down, CAPsMAN can get disconnected, but CAPs run as per normal, at least for some time. like having standalone APs all over the place, but have it's configuration managed and pushed down to the APs as and when changes are done.

I happen to work a lot with Cisco stuff and asked a colleague of mine about how it works with Cisco's controller.

With their solution if the AP loses connectivity with the controller it stops broadcasting only if set to encapsulate traffic. If it's in local forwarding, it does not stop broadcasting the wireless network BUT it does not allow any new connections.

So basically Cisco's does the same as Mikrotik's, the only difference is that it does not kick out already connected devices. But roaming between APs and all the rest are not supported when the controller is unreachable. If you're in, you stay in. If you're out, you stay out

The biggest difference I see is that you can run CAPSMAN with very little costs, even the APs themselves can run it if you want, while Cisco's is a "tad" more expensive so it's not really feasible to have a controller per every remote branch

What you can do it set up a main controller and one per branch, and feed them to the access point in that order. This way if the WAN dies the AP registers to the local controller and keeps forwarding traffic.

Now if only there was a way to associate remote controllers to a main controller to provision them all in one single place!

we will try to improve the CAPsMAN operation in future so the downtime of the CAPs operation would be less.

+1, it would be nice to be able to configure the desired behavior.

+ 1

Any update on this?
Is this the same behavior for CAPsMAN v2?

I'd also really like this functionality. UniFi supports continued operation even when the controller goes offline.

I would like a "TTL" of some sort, so that a CAP could be set to work for example 24 hours after last connecting to it's CAPSMAN.