1 CAPsMAN Troubleshooting Guide (KitsNet)[edit | edit source]
This guide documents troubleshooting procedures for the KitsNet wireless infrastructure using MikroTik CAPsMAN.
Controller: absolut (CHR) Edge router: courvoisier CAP devices: able, baker
1.1 Quick Diagnostic Checklist[edit | edit source]
When wireless problems occur, check the following first:
- Are the CAP devices connected to CAPsMAN?
- Are radios provisioned correctly?
- Are datapaths correct?
- Are clients completing WPA authentication?
- Are DHCP leases being issued?
1.2 Verify CAP Registration[edit | edit source]
On the CAPsMAN controller (absolut):
/caps-man remote-cap print
Expected output:
- able – Run
- baker – Run
If a CAP is missing:
Possible causes:
- wrong controller IP
- CAP locked to another controller
- CAP discovery blocked
- certificate mismatch
1.3 Verify Radios and Provisioning[edit | edit source]
Check radio provisioning:
/caps-man interface print
Expected radios:
- able 2.4 GHz
- able 5 GHz
- baker 2.4 GHz
- baker 5 GHz
If radios are missing:
Check provisioning rules:
/caps-man provisioning print
Common causes:
- incorrect radio MAC match
- wrong provisioning rule order
- configuration name mismatch
1.4 Check Client Associations[edit | edit source]
On the controller:
/caps-man registration-table print
This shows connected wireless clients.
Important fields:
- signal strength
- TX/RX rate
- interface name
If clients are not appearing:
Possible causes:
- WPA authentication failure
- incorrect security profile
- wrong SSID configuration
1.5 Diagnosing 4-Way Handshake Failures[edit | edit source]
Symptoms:
- clients see the SSID but cannot connect
- repeated authentication attempts
- log entries referencing handshake failures
Check controller log:
/log print where message~"handshake"
Possible causes:
| Cause | Description |
|---|---|
| Security profile mismatch | SSID uses wrong WPA2/WPA3 configuration |
| Datapath misconfiguration | bridge or VLAN incorrect |
| CAP not synchronized | radio using stale configuration |
| client compatibility issue | older devices cannot use WPA3 |
Recommended test:
Temporarily force WPA2 only.
1.6 CAP Cannot Discover Controller[edit | edit source]
Check CAP configuration:
On the CAP:
/interface wireless cap print
Important values:
- enabled: yes
- discovery interface correct
- caps-man-addresses correct
Example:
caps-man-addresses: 192.168.15.x
Test connectivity:
ping 192.168.15.x
1.7 CAP Locked to Wrong Controller[edit | edit source]
CAPs can be locked to a specific controller.
Check:
/interface wireless cap print
If necessary unlock:
/interface wireless cap set lock-to-caps-man=no
1.8 Certificate Problems[edit | edit source]
If certificates are used for CAP authentication:
Check controller certificate:
/caps-man manager print
Check CAP certificate usage:
/interface wireless cap print
Common issues:
- certificate not copied during migration
- CA mismatch
- expired certificate
1.9 Datapath Problems[edit | edit source]
Datapaths determine how traffic flows.
Check datapaths:
/caps-man datapath print detail
Important field:
- local-forwarding
Interpretation:
| Value | Meaning |
|---|---|
| yes | traffic stays on CAP |
| no | traffic tunnels to controller |
For KitsNet architecture:
- client traffic should be local-forwarded
- controller should not carry client traffic
1.10 DHCP Problems[edit | edit source]
If clients connect but cannot obtain an IP address:
Check DHCP leases.
On Courvoisier (Guest network):
/ip dhcp-server lease print
On Radix (main network):
Check LAN DHCP server.
If no leases appear:
Possible causes:
- datapath bridging incorrect
- VLAN mismatch
- firewall blocking broadcast
1.11 Signal and RF Issues[edit | edit source]
Check client signal:
/caps-man registration-table print stats
Key metrics:
- signal
- tx-rate
- rx-rate
Poor signal can cause authentication failures.
1.12 CAP Offline[edit | edit source]
If a CAP disappears entirely:
Check device:
/system resource print
Verify:
- device powered
- Ethernet link up
- bridge port active
1.13 Fast Recovery Commands[edit | edit source]
Force CAP reconnection:
On CAP:
/interface wireless cap disable /interface wireless cap enable
Restart CAPsMAN:
On controller:
/caps-man manager set enabled=no /caps-man manager set enabled=yes
1.14 Emergency Fallback[edit | edit source]
If CAPsMAN fails completely, a CAP can run standalone.
On CAP:
/interface wireless cap disable
Then configure local wireless interfaces.
This restores temporary connectivity until CAPsMAN is repaired.
1.15 Monitoring Commands[edit | edit source]
Useful commands during operations:
Controller:
/caps-man remote-cap print /caps-man interface print /caps-man registration-table print
CAP device:
/interface wireless cap print /interface wireless print /log print
1.16 Preventative Practices[edit | edit source]
To reduce wireless failures:
- keep RouterOS versions synchronized
- maintain symmetric CAP provisioning
- avoid overlapping channels
- document datapath design
- test migrations on one CAP first
1.17 Related Documentation[edit | edit source]
- Wireless Architecture
- CAPsMAN Migration Procedure
