# WiFi / CAPsMAN Troubleshooting Guide **Last Updated:** 2026-03-12 **Purpose:** Document known pitfalls, root causes, and diagnostic procedures for WiFi and CAPsMAN issues on the MikroTik HAP ax³ + cAP XL ac setup. --- ## Pitfall 1: Empty Inline Security Overrides = Open Network **Severity:** CRITICAL **Problem:** Setting `security.authentication-types=""` on a WiFi interface does NOT mean "inherit from security profile." RouterOS interprets an empty string as **no authentication (open network)**. **Symptoms:** - Devices connect but show empty AUTH-TYPE in registration table - IoT devices that try WPA/WPA2 handshake silently fail — router logs show ZERO connection attempts - Other devices connect fine (they accept open) **Root Cause:** Attempting to "clear inline overrides" to inherit from the security profile by setting empty values. RouterOS treats empty string as explicit "no auth." **Fix:** ```routeros # Always set explicit values on the interface /interface wifi set wifi2 \ security.authentication-types=wpa-psk,wpa2-psk \ security.encryption=tkip,ccmp ``` **Rule:** NEVER set `security.authentication-types=""` or `security.encryption=""`. Always use explicit values matching the security profile. --- ## Pitfall 2: CAPsMAN Re-Provisioning Wipes Interface Config **Severity:** HIGH **Problem:** Running `/interface wifi capsman remote-cap provision` clears all configuration from cap-wifi interfaces — security, channel, datapath, and SSID are all removed. Interfaces show "SSID not set" and remain inactive. **Fix:** After re-provisioning, manually re-apply full config: ```routeros # 2.4GHz (cap-wifi1 = MAC :BE = 2.4GHz radio) /interface wifi set cap-wifi1 \ configuration=cfg-xtrm2 security=sec-xtrm2 datapath=dp-cap \ channel.frequency=2472 channel.band=2ghz-g channel.width=20mhz # 5GHz (cap-wifi2 = MAC :BF = 5GHz radio) /interface wifi set cap-wifi2 \ configuration=cfg-xtrm security=sec-xtrm datapath=dp-cap \ channel.frequency=5180 channel.band=5ghz-ac \ channel.width=20/40/80mhz channel.skip-dfs-channels=all # Re-enable both /interface wifi enable cap-wifi1 /interface wifi enable cap-wifi2 ``` --- ## Pitfall 3: Interface IDs Change After Re-Provisioning **Severity:** HIGH **Problem:** After CAPsMAN re-provisioning, cap-wifi interface internal IDs change (e.g., `*20`/`*21` become `*22`/`*23`). Access-list rules referencing old IDs stop matching. **Symptom:** `client was disconnected because could not assign vlan` error on CAP interfaces. **Fix:** ```routeros # Check current IDs :foreach i in=[/interface wifi find where name~"cap"] do={ :put ([/interface wifi get $i name] . " = " . $i) } # Update access-list rules /interface wifi access-list set [find where interface=*OLD] interface=*NEW ``` **Best practice:** Don't use CAP-specific access-list rules. Let all clients (HAP and CAP) use the same MAC-based access list. The HAP handles VLAN assignment uniformly via CAPsMAN. --- ## Pitfall 4: CAP Radio-to-Interface Mapping Swap **Severity:** MEDIUM **Problem:** After re-provisioning, `cap-wifi1` and `cap-wifi2` may swap which physical radio they map to. Assigning 5GHz config to the 2.4GHz radio (or vice versa) causes "no available channels" error. **Identification:** Check MAC addresses: | MAC suffix | Radio | Must receive | |------------|-------|--------------| | :BE | 2.4GHz | 2.4GHz config (XTRM2) | | :BF | 5GHz | 5GHz config (XTRM) | **Fix:** Match config to the correct radio MAC, not the interface name. --- ## Pitfall 5: CAP Band Must Be AC, Not AX **Severity:** MEDIUM **Problem:** The cAP XL ac only supports 802.11ac. Setting band to `5ghz-ax` results in the radio not starting. **Fix:** Always use `5ghz-ac` for the CAP 5GHz channel configuration. --- ## Pitfall 6: IoT Devices Need Legacy WiFi Settings **Severity:** HIGH **Problem:** Many IoT devices (vacuums, smart gateways, ovens) require legacy WiFi settings to connect. Using 802.11n-only or WPA2-only silently prevents connections — the router sees zero attempts. **Required XTRM2 (2.4GHz) settings:** | Setting | Value | Reason | |---------|-------|--------| | Band | `2ghz-g` | NOT `2ghz-n` — IoT devices may only support 802.11g | | Auth | `wpa-psk,wpa2-psk` | Some devices need WPA1 available | | Encryption | `tkip,ccmp` | Some devices need TKIP | | Channel width | `20mhz` | Maximum compatibility | | FT (802.11r) | Disabled | Causes issues with IoT | **Known devices requiring legacy support:** - Roborock S7 Vacuum (B0:4A:39:3F:9A:14) - Tuya Smart Gateway JMWZG1 (38:1F:8D:04:6F:E4) - Bosch Oven (94:27:70:1E:0C:EE) - Various other IoT appliances --- ## 5GHz Channel Separation HAP and CAP must use different 5GHz channels to avoid co-channel interference: | Device | Channel | Frequency | Band | |--------|---------|-----------|------| | HAP wifi1 | 149 | 5745 MHz | 5ghz-ax | | CAP cap-wifi2 | 36 | 5180 MHz | 5ghz-ac | Both use `skip-dfs-channels=all` to avoid radar detection disconnects. --- ## Diagnostic Checklist When devices can't connect to WiFi, check in this order: ### Step 1: Check Security (Most Common Issue) ```routeros # Check if AUTH-TYPE is empty in registration table (= open network!) /interface wifi registration-table print # Check inline security overrides :put [/interface wifi get wifi2 security.authentication-types] :put [/interface wifi get wifi2 security.encryption] # If empty → security is broken, set explicit values ``` ### Step 2: Check Band Compatibility ```routeros /interface wifi monitor wifi2 once # If channel shows /n → change to /g for IoT compatibility ``` ### Step 3: Enable Debug Logging ```routeros /system logging add topics=wireless,debug action=memory # Then check: /log print where topics~"wireless" ``` ### Step 4: Check CAP Interface IDs ```routeros # Verify access-list rules reference current IDs :foreach i in=[/interface wifi find where name~"cap"] do={ :put ([/interface wifi get $i name] . " = " . $i) } /interface wifi access-list print where interface~"\\*" ``` ### Step 5: Check Radio-MAC Mapping ```routeros # Verify cap interfaces are assigned to correct radios /interface wifi print where name~"cap" proplist=name,mac-address,channel.band ``` ### Step 6: If Router Sees ZERO Attempts This means: - **Security mismatch** — device won't even try (most likely empty auth = open) - **Band incompatibility** — 802.11n-only blocks 802.11g devices - **Device-side issue** — power cycle device, re-do WiFi setup from scratch --- ## Quick Recovery Commands ### Restore XTRM2 (2.4GHz) to known working state ```routeros /interface wifi security set sec-xtrm2 \ authentication-types=wpa-psk,wpa2-psk encryption=tkip,ccmp /interface wifi set wifi2 \ security.authentication-types=wpa-psk,wpa2-psk \ security.encryption=tkip,ccmp \ security.ft=no security.ft-over-ds=no /interface wifi channel set ch-2g-hap \ frequency=2412 band=2ghz-g width=20mhz ``` ### Restore XTRM (5GHz) to known working state ```routeros /interface wifi security set sec-xtrm \ authentication-types=wpa2-psk,wpa3-psk encryption=ccmp /interface wifi set wifi1 \ security.authentication-types=wpa2-psk,wpa3-psk \ security.encryption=ccmp \ security.ft=no security.ft-over-ds=no /interface wifi channel set ch-5g-hap \ frequency=5745 band=5ghz-ax width=20/40/80mhz skip-dfs-channels=all ``` ### Restore CAP interfaces after re-provisioning ```routeros /interface wifi set cap-wifi1 \ configuration=cfg-xtrm2 security=sec-xtrm2 datapath=dp-cap \ channel.frequency=2472 channel.band=2ghz-g channel.width=20mhz /interface wifi set cap-wifi2 \ configuration=cfg-xtrm security=sec-xtrm datapath=dp-cap \ channel.frequency=5180 channel.band=5ghz-ac \ channel.width=20/40/80mhz channel.skip-dfs-channels=all /interface wifi enable cap-wifi1 /interface wifi enable cap-wifi2 ```