Addresses #94, phases A and B. Write operations are deliberately out of scope.
An access point provisioned by CAPsMAN holds none of its own wireless
configuration, so /interface/wifi/print returns rows with the configuration.* and
security.* fields absent. normalizeWifiInterface mapped nothing, stored nulls, and
the UI rendered an AP with no SSID, security or band — indistinguishable from one
that is simply broken.
Phase A — stop showing blanks
Devices are classified standalone / cap / controller / controller_cap from
/interface/wifi/capsman and /interface/wifi/cap. Both toggles can be on: MikroTik
supports a controller that also runs its own radios under itself, and the issue
calls that case out, so it gets its own role.
Provisioned interfaces are marked and labelled in the Radios tab with the
controller's MAC and an explanation that the blank fields live on the controller.
SSID, mode and channel are recovered from RouterOS's status line where present,
so the AP is described rather than blank.
Role is the signal, not missing data: an AP whose SSID is empty because the
controller owns it looks identical to an unconfigured one, and only the toggle
distinguishes them. A CAP can still hold locally-configured interfaces alongside
provisioned ones, so per-interface state is checked rather than assuming the
whole device.
Phase B — read-only controller view
Controllers now collect the radios they manage, named configurations, and
provisioning rules, surfaced as a CAPsMAN panel on the Wireless page grouped by
the access point each radio physically lives on.
CAPs are matched to managed devices by radio MAC from the controller's own
/interface/wifi/radio list, not by resolving addresses through neighbours as the
issue proposed. A MAC is hardware identity and globally unique, so unlike an
address it cannot mean two devices on two segments — the failure fixed in
v0.20.1. A radio MAC often differs from the interface MAC in the final octet, so
lookup falls back to a five-octet prefix while keeping the OUI exact. A CAP that
is not a managed device is surfaced rather than hidden; that is usually the
reason an AP appears to be missing from the fleet.
The wireless section required device_type = 'wireless_ap' in five places, which
hid a dedicated controller — normally classified as a router — from every
wireless view. Collection was gated the same way. Both now include CAPsMAN roles,
and the collector probes an unknown device once, records the role, and skips
cheaply forever after.
Not included
Provisioning, config edits and interface enable/disable. A CAPsMAN configuration
applies to every AP bound to it simultaneously, which is the fleet-wide version
of the failure Change Guard exists to prevent. It needs the same prediction and
revert treatment rather than being bolted on. Legacy /caps-man (pre-RouterOS 7)
is a separate API tree and is not covered.
Verified: API shapes probed against RouterOS 7.23 rather than taken from docs.
24 unit tests on the pure parsing and matching. No CAPsMAN hardware here, so the
read path was exercised against a seeded controller with a local radio, a matched
two-radio CAP and an unmanaged CAP; grouping, provisioning and SSID resolution all
came out correct. Confirmed no regression on a fleet with no controller: roles
detected correctly, no interface falsely flagged, wireless views unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2GT-RichandClaude Opus 5
14bab24c7e