CAPsMAN provisioning silently no-ops for remote CAP on MediaTek chip (mt7992) when manager runs Qualcomm radios (ipq5332/qcn9274) — RouterOS 7.23.3

RouterOS Wireless Networking
1

Setup:

  • Manager: MikroTik hAP be³ Media (board-name "hAP be^3 Media"), RouterOS 7.23.3, radios: wifi1=ipq5332, wifi2/wifi3=qcn9274 (all local, running fine standalone)
  • CAP: MikroTik hAP BE Lite (board-name "A42G-HbeP"), RouterOS 7.23.3 (upgraded from 7.22.2 mid-troubleshooting, no change), radios: wifi1/wifi2 = hw-type "mt7992"
  • New unified /interface/wifi CAPsMAN (not legacy /caps-man)

What I did:

  1. Factory reset the hAP BE Lite (Remove Configuration in Winbox), confirmed fully blank (no bridge, no firewall, no IP anywhere).
  2. On manager: /interface/wifi/capsman set enabled=yes (fresh — was never used before, generated CA/certificate automatically).
  3. Created two /interface/wifi/configuration profiles (2.4GHz + 5GHz), ssid=AlzolayMK, wpa2-psk/wpa3-psk, ft=yes, country=Chile, datapath.bridge=bridge-Lan.
  4. Created two /interface/wifi/provisioning rules matched by exact radio-mac (confirmed byte-for-byte against /interface/wifi/radio/print on the CAP itself), action=create-dynamic-enabled, pointing to the profiles above.
  5. On CAP: /interface/wifi/cap set enabled=yes discovery-interfaces=all.

Result:

  • CAP connects successfully every time: /interface/wifi/capsman/remote-cap/print shows state="Ok", correct identity/board-name/serial, connected-time increasing normally.
  • CAP's own /interface/wifi/print permanently shows wifi1 and wifi2 as "SSID not set", mode=ap, no security applied — never gets provisioned.
  • current-country on the CAP's radios stays at factory default ("Latvia"), never picks up country=Chile from the profile — indicates the config is never actually pushed, not just a display issue.
  • Manual /interface/wifi/capsman/remote-cap/provision [find ...] on the specific remote-cap entry: no error, no effect.
  • Same manual "Provision" action via Winbox GUI (CAPsMAN > Remote CAP > right-click > Provision): identical no-op.
  • No relevant log output at all (topics=wireless,caps) on either the manager or the CAP — no rejection, no error, nothing.

Things ruled out (each tested in isolation, with before/after verification):

  • Wrong table (used /interface/wifi/capsman/remote-cap, not /interface/wifi/radio which is local-only on the manager; confirmed /interface/wifi/capsman/provisioning doesn't even exist as a path — provisioning rules live under /interface/wifi/provisioning).
  • Band-based matching (supported-bands=2ghz-ax/5ghz-ax) vs exact radio-mac matching — tried both, same result.
  • action=create-dynamic-enabled confirmed used throughout (not bare create-dynamic).
  • Missing local bridge on the CAP for datapath.bridge to attach to — created /interface/bridge name=bridge-Lan with ether1 as member on the CAP — no change.
  • datapath.bridge property itself — removed it entirely from the profile — no change.
  • RouterOS version mismatch — CAP was on 7.22.2, upgraded to 7.23.3 to match manager exactly — no change.
  • CAP having no IP address — added a DHCP client on the CAP's bridge, confirmed it got a lease from the manager's DHCP server — no change.
  • Stale/leftover config from earlier troubleshooting — did a full factory reset and rebuilt everything from scratch in one clean pass — no change.

Working theory: CAPsMAN's provisioning push may not be implemented/working for a MediaTek radio (mt7992) when the manager itself only has Qualcomm radios (ipq5332/qcn9274) locally — i.e. possibly the manager's wifi package doesn't carry whatever driver-specific logic is needed to configure an mt7992 radio remotely, even though the CAPsMAN protocol layer (discovery/connect) is chipset-agnostic and works fine.

Question: is cross-vendor (Qualcomm manager ↔ MediaTek CAP) provisioning supported at all in the current /interface/wifi CAPsMAN implementation? If so, what am I missing? Happy to provide /interface/wifi/radio/print detail from both ends, full config export, or a supout.rif if useful.

2

What happens if you try to configure the device directly in the WiFi tab from the CapsMan server, and bypass "Provision"?

I've hit cases of incompatible default options keeping things from coming up.

3

Easy fix, run on CAP:

/system/reset-configuration caps-mode=yes

4

@infabo — thanks, /system/reset-configuration caps-mode=yes on the CAP fixed it. I confirmed it properly (not just "connected", but that the config was actually applied): right after the reset, Winbox briefly shows the default-configuration screen — that's normal, just click OK. A minute later, both radios showed the correct country (Chile) instead of the factory-default country that kept showing up before this fix. That country field is the best way to confirm the profile actually got pushed, not just that the CAP connected.

My setup: hAP BE Lite (mt7992) as CAP, under a manager with Qualcomm radios (ipq5332/qcn9274, hAP be³ Media), RouterOS 7.23.3 on both ends.

Heads-up for anyone else who gets this far with the same issue: once provisioning actually works, CAPsMAN automatically groups the CAP's two radios into MLO (WiFi 7 multi-link) mode. This caused client devices to connect and disconnect every few seconds near the CAP, even with strong signal — basically unusable. Everything looked fine from the manager's side. I spent a while chasing it as a roaming/FT issue before finding the real cause.

The fix: set multi-link-mode=disabled on the relevant /interface wifi provisioning rule. Note: this change does not apply to an already-connected CAP — you have to force it to reprovision with: /interface wifi capsman/remote-cap/provision [find address~""] (use the CAP's specific MAC, don't leave it unfiltered since that also hits the manager's own local radios). After that, the MLO grouping disappears and clients stay connected normally.

Posting this in case it saves someone else some time after getting past the provisioning block.