RouterOS CMR
Grounded on RouterOS 7.26beta1, x86 CHR, with four disposable routers and three quickchr socket links. The controller, a transit client, a remote client reachable through OSPF, and a direct discovery client exercise different paths. The runnable example and evidence report are the reproduction surface. No later beta, arm64 CHR or WiFi radio was verified by this lab.1
CMR manages RouterOS devices: inventory, resource/availability/log alerts, fleet scripts and upgrades, topology, and WiFi/VLAN provisioning. It does not provide general ping/SNMP/HTTP monitoring of non-RouterOS equipment.2
Versions and packages
CMR first appeared in 7.26beta1. Pin that version for reproductions and record
both the controller and client versions. The lab installed the optional cmr
package only on the controller; clients used the built-in /cmr/client.1
The manual lists arm, arm64 and x86 for the server package. Clients exclude smips and powerpc. A mipsbe client was observed in the earlier hardware session; that architecture was not re-tested in the CHR lab.23
Server, service and client discovery
routeros/cmr set enabled=yes track-topology=yes fetch-comments=yes auto-labels=all
The controller lists its own built-in client in /cmr/device. A dynamic service
named cmr listens on TCP/54321. Scope this service with the input firewall.
In the lab, CMR was blocked on each host-management NIC so pairing used only the
socket topology.1
routeros/cmr/client set enabled=yes controller-addresses=10.255.0.1
The remote client reached that controller loopback through a transit router,
with an asserted active OSPF route. A direct client with no
controller-addresses discovered the controller on its socket link. DHCP-based
discovery and application traffic collection remain manual-only claims.12
Read /cmr/client for status, pairing-status, controller-address and
controller-identity. The lab observed waiting-for-pairing,connected becoming
paired,connected. Paired clients reconnected with pairing intact after a clean
/system/reboot, a hard power-off and a controller reboot.1
A reconnect can stall for one TCP SYN timeout (about 90 seconds) when the route to the controller is briefly withdrawn while a default route exists. The connect leaves via the default route, and its retransmits keep that source address after the specific route returns. The lab first misread this as a CMR reconnect bug. It now rejects tcp/54321 out of its management NIC with a TCP reset.1
The controller's own /cmr/device row reports connected=false, although its
self-client is paired and fleet scripts execute on it. Do not require the C flag
on that row when checking fleet readiness.1
/cmr/client/forget clears pairing. Disabling the client removes CMR-managed
(Y) configuration according to the manual.2 On 7.26beta1, client
disable/enable also cleared the client-side pairing approval. The client came
back waiting-for-pairing,connected with password required, and the
controller flagged the device REMOTE-PENDING until it was paired again. A reboot
did not do this. Avoid toggling enabled on a paired client unless re-pairing
is acceptable.1
Pairing: satisfy both sides
On 7.26beta1, client completion offers none and password; setting client
pairing-requirement=confirm returns syntax error (line 1 column 37). The manual
also describes confirm on clients. This mismatch is reproduced and has a
prepared support report; do not silently assume the documented value works.12
The server's per-device requirement accepts none, password and confirm.
The unpaired device state spells out both requirements as
device:<client condition>, cmr:<server condition>.1
| Client requirement | Server per-device requirement | Fresh pairing verified with |
|---|---|---|
| none | none | automatic acceptance |
| none | password | client pair with controller login |
| none | confirm | controller device/pair without credentials |
| password | none | controller device/pair with client login |
| password | password | client pair with controller login |
| password | confirm | controller device/pair with client login |
All six combinations reached paired,connected. Running pair locally approves
that side, so password/password does not require two commands when one side
approves itself locally and supplies the remote side's login.12
routeros# On the controller, using a RouterOS account ON THE CLIENT: /cmr/device/pair [find identity="lab-client"] username=client-user password="..." # On the client, using an account ON THE CONTROLLER: /cmr/client/pair username=controller-user password="..."
There is no separate CMR pairing password. The current manual explains remote
RouterOS credentials; a former draft's claim that it required "server credentials"
for server-side pair was an interpretation of older wording.12
Use real client credentials and explicit controller approval for the normal
flow. Client-side none accepts pairing without client approval; the
controller's independent password or confirm requirement must still be
satisfied before management begins. The example uses generated quickchr logins
and does not put passwords into its reports.12
Changing an already paired client from none to password made it pending in
the prior hardware session. Global /cmr pairing-requirement, wrong-password
negative controls and that transition were not re-tested by the six-case
matrix, which uses fresh pairings and per-device requirements.3
Labels, fleet scripts and topology
Set explicit labels on devices and select them for rules and commands:1
routeros/cmr/device/set [find identity="lab-client"] labels=lab,remote /cmr/device/run-script labels=lab script=":put [/system/identity get name]" /cmr/layout/add name=lab /cmr/layout/add-devices [find name=lab] labels=lab /cmr/layout/rebuild-links [find name=lab]
The lab returned four successful fleet-script outputs and generated four nodes and three links matching its socket topology. Script results include progress sections: the controller's successful output can appear in multiple sections. Check the final successful result per device, rather than counting all output occurrences.1
Plain labels are OR; +label requires a label and -label excludes it. Combined
label predicates were not exercised by this lab. Maps and dashboards are shown
in WinBox 4/WebFig; GUI rendering was not verified here.2
Alerts and HTTP webhooks
routeros/cmr/alert/add name=down labels=remote disconnected-more-than=10s \ action.log="DOWN [identity] [address]" severity=high
Eight example rules were disabled by default. The lab adds enabled CPU, memory, disk, reboot, bridge-interface, log, version and availability rules. Log and interface events and HTTP POST delivery are core executable checks. A real VM stop/restart, with down and reconnect webhooks, is an extended probe. Resource exhaustion, successful/failed upgrades and health sensors were not induced.1
upgrade-done takes success or fail in the observed default rules; do not
write it as a boolean. The lab uses upgrade-done=success without upgrading.1
The first bridge added to a device that has no bridges does not fire
interface-change=added, typed or untyped. Later additions fire within seconds.
Reproduced on three clients. It is per device, not per rule: a rule created after
a device already had a bridge fired on its first match. interface-type offers
only any, ethernet, wifi and bridge; VRRP additions never alerted.
The example keeps a --first-bridge reproducer. The default lab creates a bridge loopback on each router before CMR starts.1
Log alerts install a managed /system/logging entry on the client with
action=cmr, the requested topics and regex. Wait for that entry before emitting
a test log. The lab emits a fresh marker and requires the alert to fire.1
Webhook actions use action.http-url, action.http-method, action.http-body
and action.http-headers. The example receives substituted device data at an
ephemeral host listener via the QEMU user gateway, with an explicit
Content-Type: text/plain. It checks action-failures as well as delivery.1
connected=yes reset-on-disconnect=yes is configured for reconnect alerts.
The lab records initial connected and actual down webhook messages and fired
counters, and the extended probe also receives the reconnected webhook. Rule evaluation
can take up to a minute; use bounded state polling instead of assuming immediate
execution.12
The earlier hardware session saw [address]=unknown while a client was down and
an empty address for the controller. Treat that as a versioned observation, not a
stable address lookup; identify devices with an explicit identity or label.3
Actions can also run named scripts. Script permissions, additional placeholders,
alert/test, show-devices and health thresholds remain docs-only here.2
Upgrade rules and package directory
A dynamic, read-only default rule selects stable. On the beta controller it
offered 7.24.5, an older release, and editing it returned
can't edit default rule. A U flag means a different offered version; it does
not prove that installing it is an upgrade.1
Add a lab rule without a schedule:1
routeros/cmr/upgrade/add name=lab-pinned labels=lab channel=7.26beta1 \ strategy=sequential fail-policy=stop
The example asserts that every device selects this rule and never calls
upgrade or trigger. Package retention on a downgrade was not tested; the
old draft's claim that a downgrade necessarily removes CMR is not established by
this lab.1
packages-directory must name an existing directory and end with /:1
routeros/file/add type=directory name=cmr-packages /cmr set packages-directory=cmr-packages/
Without the slash the lab received input does not match any value of packages-directory. Changing it restarts CMR and clients reconnect; the manual
now documents both behaviors. Do not report these as new bugs. Cache settings
and scheduling details should be read from the current manual instead of
assuming the prior hardware cache limit is a universal default.12
Export versus binary backup
On 7.26beta1, /cmr/export, /cmr/export verbose and full /export verbose
omit the controller's /cmr set settings, including enabled=yes and the custom
package directory. Rules/layouts appear, but the paired device inventory is also
absent. Export alone is insufficient to reproduce the running controller.1
A real binary backup was saved, CMR was disabled, and the backup was loaded. After the resulting reboot, server settings, device identities, labels and pairing IDs matched the saved state. Keep a binary backup for this beta and separately record the controller settings when relying on exports.1
Still docs-only or outside the lab
WiFi and VLAN provisioning, DHCP discovery, apptraffic, dashboard GUI, push-button pairing, global server pairing policy, ARM servers and later betas need separate experiments. CHR has no WiFi radios or physical health sensors; do not turn a configured rule into a claim that those hardware paths work.2
Footnotes
-
quickchr CMR example, beta evidence and support drafts, RouterOS 7.26beta1, x86 CHR, 2026-10-05 local date. Executable core checks:
cmr.ts; additional pairing/export/backup probes:tool/probes.ts. No later release was tested. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25 ↩26 ↩27 ↩28 -
MikroTik CMR manual and
/cmrCLI reference, read 2026-10-05. A docs-only citation is not runtime validation. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 -
Earlier 2026-10-05 observation on 7.26beta1: an arm64 controller, a mipsbe client and a routed x86 CHR. These specific claims were not re-tested by the four-CHR lab; kept as explicitly limited prior observations. ↩ ↩2 ↩3
