WiFi on RouterOS 7: The wifi Driver, CAPsMAN v2, and Roaming That Works

Half the “MikroTik WiFi is broken after upgrade” threads on the forum come down to one misunderstanding: RouterOS 7 has two entirely separate wireless stacks, and your hardware decides which one you get. People upgrade a hAP ac², see their wireless config gone or their CAPsMAN controller refusing to adopt the AP, and assume a bug. It’s not a bug. It’s a driver split that MikroTik communicated badly.

The new stack — /interface/wifi — is genuinely better. WPA3 that works, 802.11r fast transitions, 802.11k/v steering, a sane profile-based configuration model, and a rewritten CAPsMAN that no longer hairpins your traffic through the controller. But you have to understand which package your hardware runs, and the configuration model is different enough from the old /interface wireless that copy-pasting v6-era configs will fail.

This article covers the package split, the configuration model, CAPsMAN v2 provisioning with per-SSID VLANs, WPA3 transition mode, and roaming. If you’re running an all-MikroTik WiFi deployment on RouterOS 7, this is the setup I’d defend in a design review.

Two Stacks, Three Packages

RouterOS 7 ships wireless support in separate driver packages:

• wifi-qcom — the new driver for 802.11ax hardware: hAP ax lite, hAP ax², hAP ax³, cAP ax, wAP ax, Audience-class successors, Chateau ax. These devices run the /interface/wifi menu natively. This is where all new development happens.
• wifi-qcom-ac — an alternative driver for 802.11ac hardware with ARM CPUs: hAP ac², hAP ac³, cAP ac, wAP ac (the ARM revision), Audience, NetMetal ac². Installing it (and removing the legacy wireless package) moves those radios into the /interface/wifi menu with most of the new features — WPA3, OWE, 802.11w, 802.11r/k/v.
• wireless — the legacy driver. Still the only option for MIPSBE devices (hAP ac lite, older wAP ac revisions, mANTBox and friends) and for oddballs like the RB4011’s wireless card, which the new driver does not support. Legacy /interface wireless still exists precisely because a large chunk of the installed base physically cannot run the new stack.

Two operational caveats before you convert an ac device. First, wifi-qcom-ac is heavier on RAM — on a 128 MB cAP ac you will feel it, and running much else on the device becomes uncomfortable. Second, the conversion is a package swap: uninstall wireless, install wifi-qcom-ac, reboot — and your wireless configuration does not migrate. Export it first, rebuild it in the new syntax.

Check what you’re running:

/system package print
# Look for: wifi-qcom, wifi-qcom-ac, or wireless

The /interface/wifi Configuration Model

The old driver piled everything onto the interface and its security-profile. The new model is compositional: an interface references profiles, and profiles can nest. The building blocks:

• /interface/wifi/configuration — SSID, country, and references to the other profiles
• /interface/wifi/security — authentication types, passphrase, FT settings
• /interface/wifi/channel — band, width, frequency
• /interface/wifi/datapath — bridge membership and VLAN
• /interface/wifi/steering — 802.11k/v behavior

You can also set any property inline on the interface with dotted notation (security.passphrase=...), which is fine for a standalone AP but gets messy fast. For anything you intend to maintain, use named profiles.

Minimal standalone AP:

/interface/wifi/security add name=sec-main authentication-types=wpa2-psk,wpa3-psk \
  passphrase="use-a-real-passphrase-here" wps=disable

/interface/wifi/configuration add name=cfg-main ssid=example-corp country=Kazakhstan \
  security=sec-main

/interface/wifi set wifi1 configuration=cfg-main channel.band=5ghz-ax \
  channel.width=20/40/80mhz disabled=no
/interface/wifi set wifi2 configuration=cfg-main channel.band=2ghz-ax \
  channel.width=20mhz disabled=no

A second SSID on the same radio is a virtual interface bound to a master:

/interface/wifi add name=wifi-guest master-interface=wifi1 configuration=cfg-guest \
  disabled=no

One habit worth building: print detail shows the effective values after profile inheritance, while print detail config shows only what you set directly. When an AP doesn’t behave as expected, the first command tells you what it’s actually running.

/interface/wifi print detail
/interface/wifi print detail config

CAPsMAN v2: Provisioning, Not Forwarding

The new CAPsMAN lives under /interface/wifi/capsman and manages only wifi-stack radios. The old CAPsMAN managed only legacy radios. They do not interoperate — a legacy-wireless cAP cannot be adopted by the new controller and vice versa. In mixed fleets you either run both controllers or (better) converge the hardware.

The architectural change that matters: CAPsMAN v2 does not forward user traffic through the manager. The old “capsman forwarding” mode — where every client frame tunneled to the controller — is gone. The manager pushes configuration; the CAP bridges traffic locally. This removes the controller as a throughput bottleneck and a single point of failure for the data plane, and it means your access switch ports must carry the client VLANs, because that’s where the traffic now egresses.

Controller side:

/interface/wifi/capsman set enabled=yes ca-certificate=auto

CAP side (this is also what the reset-button CAP mode does):

/interface/wifi/cap set enabled=yes discovery-interfaces=bridge
# or point it at the manager explicitly:
/interface/wifi/cap set enabled=yes caps-man-addresses=10.0.10.1

If the manager itself has radios you want it to manage, set them to configuration.manager=capsman-or-local — a manager cannot adopt its own interfaces in pure capsman mode.

Provisioning rules match radios by capability and stamp configurations onto them:

/interface/wifi/provisioning add action=create-dynamic-enabled \
  supported-bands=5ghz-ax master-configuration=cfg-main \
  slave-configurations=cfg-guest

/interface/wifi/provisioning add action=create-dynamic-enabled \
  supported-bands=2ghz-ax master-configuration=cfg-main

Verify adoption and provisioning:

/interface/wifi/capsman/remote-cap print
/interface/wifi print where dynamic
/interface/wifi/registration-table print

VLAN per SSID with Datapaths

Per-SSID VLANs are a datapath property. The CAP tags client traffic into the VLAN and drops it into its local bridge — which means the CAP’s bridge must have vlan-filtering=yes and its uplink must be a tagged trunk carrying those VLANs. I covered bridge VLAN filtering earlier in this series; it applies unchanged here.

/interface/wifi/datapath add name=dp-main bridge=bridge1 vlan-id=10
/interface/wifi/datapath add name=dp-guest bridge=bridge1 vlan-id=20

/interface/wifi/configuration set cfg-main datapath=dp-main
/interface/wifi/configuration set cfg-guest datapath=dp-guest

Note the package asymmetry: CAPs running wifi-qcom accept vlan-id pushed via datapath from CAPsMAN. On wifi-qcom-ac CAPs this doesn’t work the same way — the usual workaround is to configure the bridge and VLAN tagging locally on the CAP. If your fleet mixes ax and converted ac hardware, test VLAN assignment on both before rolling out.

Verify from the wired side — a client on the guest SSID should source traffic from VLAN 20 on the trunk:

/interface/bridge/host print where vid=20
/interface/bridge/vlan print

WPA3 and Transition Mode

WPA3-Personal on the new stack is one property:

/interface/wifi/security set sec-main authentication-types=wpa2-psk,wpa3-psk

That’s transition mode: WPA2 and WPA3 clients coexist on one SSID, and the driver handles the 802.11w management-frame-protection requirement that WPA3 mandates. In practice transition mode works for laptops and phones from the last five or so years. What breaks it is cheap IoT — devices with broken 802.11w handling that fail to associate or drop off silently. The pragmatic pattern is unchanged from every enterprise deployment I’ve done: corporate SSID on wpa2-psk,wpa3-psk, a separate IoT SSID on plain wpa2-psk in its own VLAN with a firewall policy that assumes those devices are hostile.

For open guest networks, prefer OWE transition over plain open — it gives opportunistic encryption without a passphrase. The docs ship a provisioning example pairing an open master configuration with an OWE slave configuration for exactly this.

Roaming: 802.11r, 802.11k, 802.11v

Roaming quality is the whole reason to run CAPsMAN instead of independent APs. Three mechanisms, all supported on the new stack:

802.11r (fast transition) moves the key exchange ahead of the roam, cutting reassociation from hundreds of milliseconds to tens — the difference between a VoIP call surviving a roam or not:

/interface/wifi/security set sec-main ft=yes ft-over-ds=yes

All APs sharing an SSID must agree on the FT mobility domain; leave ft-mobility-domain at its default unless you have overlapping deployments. Same caveat as WPA3: some older clients handle FT badly. If a specific device class starts failing to associate after enabling it, that’s your suspect.

802.11k (neighbor reports) and 802.11v (BSS transition management) are steering-profile properties — 11k tells clients which neighboring APs exist so they scan less, 11v lets the AP nudge a sticky client toward a better AP:

/interface/wifi/steering add name=st-main rrm=yes wnm=yes
/interface/wifi/configuration set cfg-main steering=st-main

Under CAPsMAN, APs sharing a steering neighbor group advertise each other automatically. Remember what steering can and cannot do: the client always makes the final roaming decision. 11k/v are suggestions; 11r makes the roam cheap once the client commits.

Verify roaming behavior with the registration table — watch a client walk between APs:

/interface/wifi/registration-table print
# repeat and watch which interface/CAP the client MAC appears on
/interface/wifi/registration-table monitor [find where mac-address=AA:BB:CC:DD:EE:FF]

Closing Thoughts

The mental model that keeps this manageable: hardware picks the package, the package picks the menu, and everything in the new menu is profiles. Check /system package print before you plan anything. ax hardware and ARM ac hardware belong on /interface/wifi; MIPS devices stay on legacy wireless, and if roaming and WPA3 matter to you, that’s a hardware refresh conversation, not a configuration one.

Design-wise, CAPsMAN v2’s local forwarding is the piece people miss: your VLAN and trunk design now extends to every AP’s switch port, exactly as it would with any enterprise WiFi vendor. Get the bridge VLAN filtering right on the CAPs first, then layer SSIDs and datapaths on top. And enable 802.11r/k/v from day one — retrofitting roaming onto a live WiFi network is a string of small outages you can avoid by doing it before users arrive.

Next in this series: containers on RouterOS 7 — what MikroTik’s Linux-container support is actually good for, and where it has no business running.