You have set up a controller, pasted the CAP script on the access point, and nothing happens. The AP says requesting..., no dynamic interfaces appear on the controller, and the AP broadcasts its old network or nothing at all.
This chapter is about the AP that never reports in. If the AP does not come up at all, go to A device on a PoE port does not come up. If it does join but clients do not move between APs properly, see Clients stick to the wrong AP.
The quick checks, in order
- Is the controller listening? On the router:
/interface wifi capsman print. A good answer isenabled: yeswithinterfacesnaming the interface the CAPs arrive on. On the legacy stack that is/caps-man manager printplus/caps-man manager interface print. - What does the AP itself say?
/interface wifi cap print. A good answer isenabled: yeswith a filled-incurrent-caps-man-address.requesting...means the AP hears nobody. Legacy:/interface wireless cap print. - Does the AP have an address? On the controller,
/ip dhcp-server lease print. The CAP script starts a DHCP client on its own bridge; no lease means the AP is on the wrong port or the wrong VLAN and can find nothing. - Does the controller see the AP?
/interface wifi printon the controller. A good answer is dynamic interfaces with names likecap-<identity>-24ghz. Legacy:/caps-man remote-cap print. - Is the controller provisioning?
/interface wifi provisioning print. A good answer is rules with a match count that rises as soon as a CAP reports in. - What is in the log?
/log print where topics~"caps", on both sides. That is where "not found" and "found but refused" part ways.
The usual causes, most common first
The AP and the controller are not in the same broadcast domain
This is by far the biggest one. The CAP script the tool generates sets discovery-interfaces=bridgeLocal and fills in no controller address. So the AP looks for the controller by broadcast on that bridge. Behind a router, across a VLAN boundary or at the other end of a tunnel, the AP will never find it.
The fix is one line you add on the AP yourself: /interface wifi cap set caps-man-addresses=10.0.0.1, with the controller's management address. On the legacy stack: /interface wireless cap set caps-man-addresses=10.0.0.1. The tool does not write that line.
The controller listens on the wrong interface
The field Interface on which CAPs find the controller defaults to the management VLAN if you have one. If your APs' management traffic arrives untagged on the bridge, the controller does not hear the discovery. Set the interface to what the APs actually use.
The port towards the AP is not a trunk
Give SSIDs a VLAN and those VLANs have to be tagged over the port to the AP. The tool warns about it too: The ports towards the CAPs must be trunks with the SSID VLANs tagged. On the network board a drawn cable between two devices makes that port a trunk automatically; without the board it is a guess.
The wrong package on the AP
The wifi-based CAPsMAN only talks to APs running the wifi package. A cAP ac on the old wireless package hears none of it; that belongs with the legacy stack, or with wifi-qcom-ac. Pick the wrong stack in the tool and there is no error message, there is simply nothing.
The identity does not match
Fill in something like ^cap- under Only CAPs whose identity matches and an AP with a different name is not provisioned, even though it was found perfectly well. The CAP script sets the identity to cap-01; give every AP its own name, because two devices with the same identity cannot be told apart on the network.
The AP was not at factory defaults
Old configuration, a static address from another range, or a bridge that was already there. Reset the AP, or hold the reset button for about ten seconds for CAP mode.
What the configurator does about it
In the CAPsMAN section you choose the stack (wifi or legacy), the country, the SSIDs with security, passphrase, bands, VLAN and client isolation, the channel widths, 802.11r, local forwarding on legacy, the identity regexp, the interface on which CAPs find the controller, and whether the router's own radios are managed by the controller too.
Next to the main script the tool produces a second one, Script for the CAP devices, which you paste on every access point. That script creates a bridge called bridgeLocal, puts ether1 and ether2 in it, starts a DHCP client, and enables the CAP with broadcast discovery on that bridge. If your AP has only one port, remove the line for ether2: the tool does not know how many ports the AP has, because the AP is not the device you generated for.
In a site with several devices there is one extra check: if there is a controller in the site while other devices have the access point role, the tool reports that those APs are set up as standalone and that you should use the controller's CAP script instead.
Not done: giving the CAP a fixed controller address, checking that the AP can reach the controller, making the identity unique per AP, or finding out which package runs on the AP. On the legacy stack the tool does warn that WPA3 does not exist there and that your SSIDs become WPA2-PSK.
When it is not your router
A switch between controller and AP that filters broadcast, a management VLAN that does not continue across that switch, or an AP on a RouterOS version too far out of step. The controller is set to upgrade-policy=suggest-same-version, but it cannot hand out a package it does not carry itself.
Read on: CAPsMAN, CAPsMAN across sites and Wi-Fi plan.