1) pull it out of the scan rotation,
2) run Frequency Usage/Scan,
3) account for the channels of your own neighboring CAPs,
4) assign the channel through a provisioning override,
5) check registration-table and roaming,
6) move to the next one.
Never scan all access points at the same time. You’ll take down the entire mesh network at once.
1. Diagnosis
One access point is just Wi-Fi. Ten access points in CAPsMAN means a free channel needs to be found for every single point in the mesh. A “spread it automatically” channel plan for the whole network just doesn’t work here.
Write one channel into the config for the entire deployment, and you’ll end up with three of your own CAPs on the same floor sitting on the same frequency, elbowing each other worse than they would with a neighbor through the wall.
Classic scenario: a client walks down the hallway, signal drops, roaming should hand it off to the neighboring CAP, but that CAP is already packed with the same frequency as the previous one. The phone doesn’t switch. It just drops packets. The logs show everything green the whole time.
What you’ll get out of this: a step-by-step procedure for scanning and assigning a channel to each access point individually, accounting for neighbors inside your own mesh, not just external networks.
Time needed: 10-15 minutes per access point. For 10 points, plan on two to three hours including roaming checks between neighboring pairs.
What you need: a list of access points with their physical location (floor/zone), access to CAPsMAN, and a window where you can disconnect clients from one access point at a time.
2. Causes
| Cause | Why it breaks the mesh |
|---|---|
| Same channel on neighboring CAPs | The access points see each other as a conflicting BSS. Both fight for airtime. Clients moving between them lose packets |
| Scanning all access points “in bulk” at once | Frequency scan disconnects clients for the duration. Run it on 10 points in parallel and the whole network drops at once |
| Channel plan with no topology awareness | Auto-selection looks at the airwaves around one specific CAP. It has no idea there’s another CAP from the same mesh 15 meters away |
| Mixed drivers across access points (wireless / wifi-qcom) | A mixed fleet. Scan behaves differently on each driver, seeing neighbors differently. The plan has to be synced manually |
| DFS on 5 GHz for some access points | One CAP leaves its channel after a radar hit, the neighbor stays put. The overlap zone ends up with a coverage hole |
| Wrong order of going through access points | You assigned a channel to the first point before finding out the second one was already sitting on it. Reworking the plan after the fact costs more |
| tx-power not recalculated after a channel change | Old power level left in place. Neighboring cells overlap more than they should at the new frequency |
3. Fix
Preparation
| Component | Version |
|---|---|
| RouterOS (stable branch) | 7.24.2 |
| RouterOS (long-term) | 7.23.5 / 6.49.21 |
| AC access point driver | wireless or wifi-qcom-ac |
| AX access point driver (Wi-Fi 6) | wifi-qcom |
At the time of writing, 7.24.2 is current. Before scanning, check for recent releases. Patches for the wifi stack come out regularly.
Before you start, build a map of access points: CAP name, physical zone, band (2.4/5 GHz), driver. Without this map, “step by step per access point” turns into chaos.
/interface/wifi/capsman/remote-cap/print
Result: a list of all connected CAPs with their identifiers. This is your worklist.
Back up right now.
/export file=capsman-mesh-before-channel-plan
Mesh walkthrough architecture
The walkthrough is strictly sequential. Finish one access point, only then move to the next.
Step 1. Take the next access point from the list
Open remote-cap. Pick a CAP you haven’t touched yet. Record its radio-mac and current interface.
/interface/wifi/capsman/remote-cap/print detail
Result: confirmation that the access point is online and ready for diagnostics.
Step 2. Scan the airwaves specifically for this access point
For wifi-qcom (Wi-Fi 6):
/interface/wifi/frequency-scan wifi1 duration=15s
For legacy wireless (AC access points):
/interface wireless frequency-monitor wlan1
Watch load (or USE) and noise floor. The lower the load and the better the noise, the freer the channel.
Also check neighboring networks:
/interface/wifi/scan wifi1
Result: a map of channel load specifically around this access point, not averaged across the whole network.
Keep in mind: frequency-scan disconnects clients on this access point. Do it fast.
Step 3. Cross-check against already assigned neighbors
Keep a table of “access point → channel” and check the distance to already-processed neighbors before assigning anything.
| Access point | Zone | Band | Assigned channel |
|---|---|---|---|
| cap-office-1fl-a | Floor 1, entrance | 2.4 GHz | 1 |
| cap-office-1fl-b | Floor 1, warehouse | 2.4 GHz | 11 |
| cap-office-3fl | Floor 3, open space | 2.4 GHz | 6 (candidate) |
If the signal between floor 1 and floor 3 doesn’t physically overlap, you can reuse the channel. If the floors are open (atrium, stairwell), space channels out more strictly, even if the distance suggests “shouldn’t interfere.”
On 2.4 GHz, work only with 1, 6, 11. Everything else is an adjacent channel, and it will interfere.
Step 4. Assign the channel to this specific access point (override, not the shared config)
For wifi-qcom, use a provisioning override targeting a specific CAP, not the shared provisioning profile:
/interface/wifi/channel
add name=ch-3fl-office frequency=2437 width=20mhz band=2ghz-ax
/interface/wifi/provisioning
add action=create-dynamic-enabled master-configuration=cfg-office \
name-format=identity radio-mac=AA:BB:CC:DD:EE:03 channel=ch-3fl-office
For legacy CAPsMAN, use a separate channel object bound to the specific access point:
/caps-man channel
add band=2ghz-onlyn control-channel-width=20mhz frequency=2437 name=ch-3fl-office tx-power=17
/caps-man provisioning
add action=create-dynamic-enabled master-configuration=cfg-office-3fl \
radio-mac=AA:BB:CC:DD:EE:03
Result: the channel is set specifically for this access point. Other points in the provisioning aren’t touched.
Right after applying, confirm the frequency actually changed:
/interface/wifi/print detail where radio-mac=AA:BB:CC:DD:EE:03
Step 5. Check this access point and its roaming neighbors
/interface/wifi/registration-table print where interface~"cap-office-3fl"
Watch signal and rate. If rate is low while signal looks fine, the channel is still dirty.
If there’s an adjacent access point nearby, walk between the zones with a phone and confirm BSSID changes without the session dropping:
/interface/wifi/registration-table monitor [find where mac-address=XX:XX:XX:XX:XX:XX]
BSSID should change. IP should stay. A video call shouldn’t drop.
Step 6. Move to the next access point
Update the “access point → channel” table. Take the next CAP on the list and repeat steps 1-5.
Don’t scan the next access point until you’ve closed out the current one. Otherwise you won’t know which change broke what.
4. Verification (across the whole mesh after the walkthrough)
# cross-check channels across all access points at once
/interface/wifi/print detail
# client roaming across the whole network
/interface/wifi/registration-table print detail
# DFS events and disconnects
/log print where topics~"wireless"
If after the full walkthrough two access points suddenly end up on the same channel, it means the “access point → channel” table wasn’t kept strictly in sequence. Revisit the plan instead of blaming it on “it just drifted somehow.”
Walk through every overlap zone with a phone, especially hallways and stairwells. Roaming should be invisible.
5. Troubleshooting
| Error | Cause | Fix |
|---|---|---|
| After assigning a channel, clients on one access point start seeing another one as interference | The provisioning applied to the whole master config instead of a specific radio-mac | Check the radio-mac in provisioning. The override needs to be targeted |
| Roaming between two neighboring CAPs drops the session | Too big a difference in tx-power. The client “sticks” to the far access point | Equalize tx-power between neighboring access points in the same zone |
| After the walkthrough, one access point is still on the default channel | It was skipped in the remote-cap list when building the map | Cross-check /interface/wifi/capsman/remote-cap/print against your table again |
| Scanning one access point took down clients on a neighboring one | Frequency scan was run on the wrong interface | Explicitly specify the interface name of that specific access point. Don’t rely on the default |
| “no available channels” | Country setting and frequency list don’t overlap, or width doesn’t fit | Check country and narrow width to 20mhz on 2.4 |
A single drop of poison can kill a horse. One access point missing from the “access point → channel” table and the whole mesh is in a state of “kind of works, but nobody knows why.”
6. Alternatives
Auto-provisioning without overrides. CAPsMAN assigns channels automatically from a shared frequency list. Pro: no manual table to maintain. Con: access points can accidentally land on the same channel if the frequency list is shorter than the number of points in a zone. No binding to a specific radio-mac.
External RF planning tool (Ekahau, iBwave). Builds a heatmap in advance, during the design phase. Pro: a color-coded coverage map for the client report. Con: doesn’t account for changes in the real airwaves after deployment. The plan looks great but stays static.
We picked the step-by-step per-access-point override as the primary method, because the plan is tied directly to the physical topology of this specific network, not to a theoretical signal propagation model.
7. Prevention
- Monitoring: set up Zabbix checks for the channel on each CAP separately, not aggregated. A channel match between neighbors should trigger an alert.
- Backup: export the full config before walking through the entire mesh.
/export file=capsman-mesh-before-channel-plan
- Documentation: keep the “access point → channel” table in a file next to the config backup, not in your head. Whoever changes the plan next shouldn’t have to guess.
- Rollout procedure: when adding a new access point to the mesh, check neighboring channels from the map first, then scan the new access point itself.
- Once a quarter, or after new neighbors show up nearby, do a partial walkthrough of the problem zones.
8. FAQ
Why did a neighboring access point start performing worse after I set a channel for one access point?
Most likely the provisioning override applied wider than intended, to the whole group of access points sharing that master config instead of a specific radio-mac. Check the override binding before moving to the next step.
How do I confirm roaming between two mesh access points actually works?
Walk a client device between the coverage zones of two access points and watch registration-table monitor by the client’s MAC address. BSSID should change without losing the IP and without dropping an active session (a video call, for example).
What do I do if I accidentally assigned the same channel to two neighboring CAPs during the walkthrough?
Reassign one of the two access points to the nearest non-overlapping channel (strictly 1/6/11 for 2.4 GHz). Update the “access point → channel” table and recheck roaming for that pair.
How is a step-by-step walkthrough different from a single channel plan for the whole network?
A single plan gets assigned once and doesn’t account for what’s actually happening at a given access point right now. The step-by-step walkthrough is slower, but each access point gets a channel that accounts for already-assigned neighbors. In a mesh network, that’s the only way to avoid stepping on your own tail.
Can I scan multiple access points in parallel?
No. Frequency scan disconnects clients. Do it in parallel and you’ll take down the whole network. One at a time, always.
9. Summary
We went through each access point individually instead of pushing one channel plan across the whole network. Every CAP now has its own frequency, assigned with real neighbors in mind, including your own access points sitting 15 meters apart.
Roaming between zones stopped being a gamble. A jammed airwave in one part of the office no longer drags the whole mesh down with it.
If something still drops after the walkthrough, post the zone and access point name in the comments. We’ll look into it specifically.
Author: Андрей А.
Оставайтесь на связи
Рецепты от IT-боли. Без воды, без рекламы, без маркетинговой шелухи.
Подписаться на IT-Аптеку →
