WISPs managing dozens or hundreds of MikroTik wireless access points without CAPsMAN are managing them the hard way: logging into each device individually for configuration changes, manually pushing firmware updates, and having no unified view of which clients are connected where across the network. CAPsMAN, MikroTik's Controlled Access Point system Manager, centralises wireless configuration and management so access points (CAPs) are configured, updated, and monitored from a single controller rather than device by device.

For WISPs with distributed outdoor deployments, CAPsMAN changes the operational model from device-level management to network-level management. A change to a wireless configuration profile pushes to every access point under the controller without touching individual devices. A new AP provisioned with a single DHCP option joins the controller automatically and receives its configuration without manual intervention.

CAPsMAN Architecture

CAPsMAN has two components: the controller, which runs on any RouterOS device and holds all configurations, and the CAPs, which are the access points controlled by the manager. Communication between controller and CAPs uses the CAPWAP protocol over the management network.

The controller can run on a dedicated RouterOS device or on an existing router with spare capacity, depending on the scale of the deployment. For deployments under 50 APs, the CAPsMAN controller running on the aggregation router is common. For larger deployments, a dedicated controller is preferred to isolate the management plane from the data plane.

CAPs can communicate with the controller over Layer 2 (same broadcast domain) or Layer 3 (IP-routed management network). Layer 3 is more flexible for geographically distributed deployments where all APs cannot be in the same Layer 2 segment as the controller.

Controller Configuration

Enable CAPsMAN on the controller device:

/caps-man manager
set enabled=yes

Create a security configuration for the wireless network:

/caps-man security
add name=sec-wpa2 authentication-types=wpa2-psk encryption=aes-ccm \
    group-encryption=aes-ccm passphrase=<psk>

Create a channel configuration specifying frequency and channel width:

/caps-man channel
add name=ch-2g-20 frequency=2412,2437,2462 width=20mhz band=2ghz-b/g/n
add name=ch-5g-80 frequency=5180,5260,5500 width=80mhz band=5ghz-a/n/ac

Create a datapath configuration that specifies how subscriber traffic is handled:

/caps-man datapath
add name=dp-subscriber client-to-client-forwarding=no \
    local-forwarding=no bridge=bridge1

Setting client-to-client-forwarding=no enforces subscriber isolation at the wireless layer, equivalent to the bridge horizon setting in the wired configuration. Setting local-forwarding=no sends all traffic through the controller rather than forwarding locally at the AP, ensuring your CGNAT and QoS policies are applied.

Create the configuration profile that brings these together:

/caps-man configuration
add name=config-subscriber ssid=<your-ssid> security=sec-wpa2 \
    channel=ch-5g-80 datapath=dp-subscriber \
    rates.supported=6,9,12,18,24,36,48,54 \
    rates.basic=6,12,24

Provisioning Rules

Provisioning rules define how newly connecting CAPs are configured based on their properties (identity, IP range, or interface they connected through). This is what enables zero-touch provisioning of new APs:

/caps-man provisioning
add action=create-dynamic-enabled master-configuration=config-subscriber \
    name-format=prefix-identity name-prefix=AP-

When a new AP connects to the controller with a valid DHCP address and the CAPsMAN manager address configured, the provisioning rule automatically assigns it the specified configuration and names it based on its RouterOS identity. The AP is live without any per-device configuration.

Firmware Management

CAPsMAN can push firmware updates to CAPs from the controller. Upload the target firmware package to the controller and enable upgrade on the provisioning rule:

/caps-man manager
set upgrade-policy=suggest-same-version

With this setting, CAPs running a different firmware version than what is on the controller will be suggested the controller's version. Changing to require-same-version forces the upgrade on connect, ensuring all APs run consistent firmware.

Monitoring at Scale

CAPsMAN provides a unified view of all connected APs and associated clients in /caps-man remote-cap and /caps-man registration-table. For operational monitoring of client counts, signal levels, and AP status across the full wireless estate, integrate CAPsMAN data into your NMS through SNMP polling of the controller.

For WISPs who want NOC-level visibility into their CAPsMAN deployment including alert generation when APs disconnect or client counts drop unexpectedly, NOC Enablement & Monitoring covers the monitoring stack integration. For automation of provisioning workflows and integration with subscriber management systems, Automation & Integrations covers the scripting and API work.