How do I prevent CAPs from going down if Capsman if unavailable?

RouterOS Wireless Networking
1

why do CAPs stop working, when capsman is unavailable for like 5 milliseconds?

in one case internet went down at one of the sites. connection to capsman was obviously lost and wi-fi went down. users weren't even able to use local resources like printers, because everything is wireless - no cabling whatsoever.

how do I increase the timeout? there's gotta be a way!
i refuse to believe that mikrotik wi-fi implementation is THAT bad.

i'm talking about CAPs set up with local forwarding, of course (managed by CAPsMAN, traffic processing on CAP).

2

Thats what thin clients are.

wait... you don't run caps-man locally?

You could always configure them as stand alones.

3

I've read this complaint here many times.

Although Mikrotik might have misjudged what an appropriate timeout is (I'm quite sure it's not 5ms) and this may be worth having a look at, the point of capsman is that authentication, roaming etc. are handled centrally - you guessed it - by the capsman.

Leaving the interfaces up with the users unable to connect, roam, etc. is certainly possible, but not very useful.

Capsman is meant to run locally. What locally means in any specific instance is dependent on the use case.

It may be a nice addition to have some sort of well defined failure or backup mode in case connection is lost. Capsman right now is not there. Could someone who is more familiar with other vendors' solutions chip in, and share how they handle this situation?

4

I've been experimenting with MikroTik wifi lately, and there is a handy config option that has helped in this sort of scenario: configuration.manager=capsman-or-local

The docs are sort of poorly worded about what this does, I think:

capsman-or-local - the interface will get configuration via CAPsMAN or use its own, if /interface/wifi/cap is not enabled.

I've found my cap actually falls back to a pre-configured local configuration, if I reboot or remove the unit running capsman, when this is set on my cap. Obviously the local config basically matches the capsman config, so that the ssid/passphrase/etc lines up and clients will connect. Here are the some example log entries from a remote cap (wap ax), when I rebooted my capsman (another wap ax) on purpose, showing time intervals involved:

2025-09-10 22:37:41 caps,info disconnected from wAP-ax-1@my:ma:ca:dd:re:ss%*6, failed to connect

...roughly 13 seconds later, clients are reconnecting to cap (wap-ax) running the local configuration options...

2025-09-10 22:37:54 wireless,info hi:ac:li:en:tm:ac@wifi1(ssid) connected, signal strength -65

Once capsman had rebooted, about 30 seconds later, the cap reconnected to capsman and was re-provisioned again, seamlessly:

2025-09-10 22:38:25 caps,info selected CAPsMAN wAP-ax-1@my:ma:ca:dd:re:ss%*6
2025-09-10 22:38:25 caps,info connected to wAP-ax-1@my:ma:ca:dd:re:ss%*6

Besides the 13-15 second "dead time" while AP falls back to local config and re-provisions, it's actually been quite handy for maintenance windows and testing. My wifi stays up, even with no capsman present, so long as I take the time to pre-set a local configuration and change that manager config option.

5

Adding:
you can also set secondary capsman controller in case the first one becomes unavailable (unavailability not due to network errors, otherwise the second one will not be reachable either).

6

My question was more along the lines of: wouldn't it be neat if the local/fallback configuration could be pushed from the capsman, and this could be stored the same as local configuration on the respective devices?

I think it turns out that capsman doesn't really deliver on its initial promise of only having to set a device to cap mode, provision it and never having to touch its config manually ever again. First of all with vlans for ac devices and then with this sort of backup config.

I really don't mind this because I only run at most a handful devices, but it's easy to imagine that in scenarios where you have 50 it would be a real chore. Somehow other manufacturers have this better in hand. Or do they?

7

I agree that would be a nice option for capsman, like a checkbox to “duplicate provisioned config to local” or similar. That way you still get the dynamic config but also auto fallback if the capsman spontaneously combusts or something. Also would maintain cap portability which is a nice feature of capsman vs others (ex: unifi where you can’t easily move APs to a different controller without completely resetting and readopting it).

Edit for clarity: to move to different capsman I simply delete the current capsman certificates on the cap. After that it found a new capsman and connected on it’s own.

8

If I may, to recap the nice info from codelogic:

  1. a CAPSMAN "client" (or CAP) can have an additional, local, self-standing configuration AND be nonetheless managed by the CAPSMAN device
  2. the setting "configuration.manager=capsman-or-local" is telling the CAP device to use primarily the CAPSMAN configuration BUT if this is not available, fallback to the local one
  3. so IF the CAPSMAN and "local" configurations are the same, the CAP will continue working normally (probably with some minor differences, such as ft not working?) even if the connection to CAPSMAN is interrupted, using the local one and then resume to CAPSMAN controlled as soon as the link is re-established

It seems to me like this is exactly the way all CAPSMAN setups should be configured.

Very likely (though it would be waaay over my head) it would be possible to create a script that "extracts" the configuration from CAPSMAN and replicates it "locally" as to keep the local configuration "aligned" to the CAPSMAN, to be run - say - every morning or on demand.

9

Key thing here: FT will work on radios controlled by the same ROS instance (and same steering group but that's implied).

In case of capsman, that would be across all radios controlled by that controller.
In case of 1 single device, it would be between 2.4 and 5GHz radio of that device. Obviously it will not work then towards another standalone cAP device running in local mode.

10

Would it be possible to use action=create-enabled instead of action=create-dynamic-enabled in provisioning rules to keep the wifi interfaces from going down when CAPsMAN is not available?

11

No
Personally, where reliability is essential, I use two managers: a primary and a backup.
In general, Capsman is not essentially a cloud controller, as other manufacturers have. Therefore, it has different functionality; it constantly manages access points. When designing a network, an engineer must take into account the principles of its operation. Therefore, using Capsman for remote locations via the Internet is bad practice.

12

I have run caps-man on the router or the core switch.

Ran it remotely for my inlaws off my house... but it was more a proof of concept. (Which taught me not to do that.)