Twenty access points spread over three buildings, with the same SSID and the same passphrase everywhere. One CAPsMAN controller does that from a single configuration, which is appealing. The question is not whether it can be done, but whether the link between those buildings is good enough to hang the wifi on.
Where it lives in the tool
The Router + CAPsMAN role turns the router into the controller. Alongside the ordinary script you get a second one, the CAP script, which you paste on every access point. In the CAPsMAN section you choose the type of access points (the wifi package for ax and be models, or legacy wireless for older ones), the SSIDs with their VLAN, the channel widths, 802.11r fast roaming, and the interface on which the CAPs find the controller.
That last field, Interface on which CAPs find the controller, defaults to your management VLAN. That is the heart of this chapter: CAPsMAN looks for its CAPs at layer 2, across that interface.
When it works
- Buildings on one site, joined by fibre. The trunk carries the management VLAN, the CAPs sit in the same layer 2 network as the controller, and the link rarely fails without the power failing too. This is the case CAPsMAN was made for.
- One building with several floors or wings. The same story, only shorter.
- Rented units in the same building, with a VLAN per tenant but one shared management VLAN.
When you install two
- Buildings joined over the internet. A CAPWAP session over a WireGuard tunnel over a consumer line is not a good foundation for a whole building's wifi. Latency and packet loss give you access points that keep re-provisioning.
- Locations in different countries. The country appears once in the CAPsMAN configuration and comes from the site's shared settings. One controller cannot put one building on Dutch and another on German regulatory rules.
- Buildings with a different SSID plan. The tool generates one provisioning rule per band, with one regular expression for the CAP names. That lets you decide which devices take part, but not give building A different SSIDs from building B. If you need that, it is a second controller.
- When the wifi matters more than the link. See the last section.
The management VLAN over the link
If you draw the buildings on the network board and join them with a cable, the tool makes those ports trunks at both ends with every site VLAN tagged, the management VLAN included. A CAP in building B is then in the same management network as the controller in building A, and discovery works by itself.
If the link is routed, that stops: broadcast does not cross a route. Two ways forward:
- Give the CAPs the controller's address. That is the tidy answer. Add the access point to the site with the Access point role, open the device, go to Wi-Fi and set the radio role to Managed by CAPsMAN (CAP). The field for the controller's address appears there. Without an address the access point looks by broadcast, which only works inside the same network.
- Stretch the management VLAN with EoIP or VXLAN, so the CAPs reach the controller at layer 2 after all. That works, and it costs you exactly what Stretching layer 2 or routing describes.
The CAP script the tool writes next to the controller script uses broadcast discovery on its own bridge. It contains no controller address. Over a routed link you have to add caps-man-addresses to it yourself, or configure the device individually as described above.
If your management VLAN is isolated, remember the firewall: CAPsMAN talks over UDP 5246 and 5247. The default rules accept LAN traffic to the router, so usually nothing is needed, but on an isolated management network you have to allow those two ports explicitly.
What the checks report
With a CAPsMAN controller in the site and access points on the Access point role, the tool tells you: these are set up as standalone, use the controller's CAP script to manage them centrally. That is a hint, not an error. The choice is yours.
Beyond that the tool watches that every device carries the management VLAN (or it is unreachable after pasting) and that an SSID sits on a VLAN the access point actually has.
What happens when the link drops
This is the answer you want before the installation, not after. A CAP fetches its whole wifi configuration from the controller and receives it as dynamic interfaces. Lose the controller and those dynamic interfaces go away, so the wifi in that building stops, even though the switch underneath is perfectly fine.
What you can do about it:
- RouterOS has
/interface wifi cap set slaves-static=yes, which keeps the provisioned interfaces as static rather than dynamic entries. The tool's CAP script does not set it; add it yourself if you want a building to ride out an outage. Then test it for real before you promise it. - With the
wifipackage, client traffic stays on the access point and does not pass through the controller. With legacy CAPsMAN that depends on the Local forwarding toggle, which is on by default. Never switch it off across a link between buildings: all of building B's wifi traffic would then travel to building A and back. - Put the controller in the building with the most access points. At least that building survives an outage.
- If building B's wifi is business critical, give it its own controller. Two controllers with the same SSIDs and passphrase roam perfectly well; all you lose is management from one place.
Checking after the rollout
- On the controller:
/interface wifi registration-table printand the list of remote CAPs. Every access point should be in it, under a name you recognise. - On a CAP: are there interfaces under
/interface wifi printand does it show as connected? - Walk from building A to building B with a phone and see whether it hands over without dropping the network.
- Then unplug the link between the buildings and watch what the wifi in building B does. Now you know.
Further reading: CAPsMAN, Wi-Fi plan and Stretching layer 2 or routing.