CMR: il Dude e il CAPsMAN si fondono in un controller di flotta dentro RouterOS
Da RouterOS 7.26 c'è un gestore di flotta nativo: inventario, script di massa, upgrade orchestrati e allarmi, con un server dentro un router e gli altri come client. L'abbiamo acceso su una flotta vera — CHR più un apparato reale con WiFi — e guardato a pacchetto cosa fa davvero, dove arriva e cosa firmi in cambio.
Cos'è, in una riga
CMR (Centralized Management and Repository) è il primo controller di flotta nativo di RouterOS. Se conosci i due strumenti storici di MikroTik, è facile inquadrarlo: prende il lato monitoraggio del Dude (scoperta, inventario, allarmi) e il lato provisioning centralizzato del CAPsMAN (ma esteso oltre il WiFi: VLAN, script, aggiornamenti), e aggiunge il pezzo che a entrambi mancava: eseguire comandi e upgrade su tutta la flotta in un colpo. Tutto dentro RouterOS, senza app né server esterni.
Attenzione a una cosa, perché è una delle critiche storiche a MikroTik: il CAPsMAN non era un controller vero ma un provisioner (sparava la config e ciao). CMR fa il salto sul management — inventario vivo, script, upgrade, allarmi — ma, come vedremo, sul lato radio è ancora un provisioner, non un controller RRM (Radio Resource Management: auto-canale, auto-potenza, steering — il WiFi che si auto-sintonizza) che ottimizza canali e potenze da solo. Teniamolo a mente.
L'architettura: un server, tanti client
Un apparato fa da server: gli si installa il pacchetto extra cmr. Tutti gli altri RouterOS dalla 7.26 in su fanno da client senza pacchetto aggiuntivo — il lato client è già nel sistema base. I client si collegano al server su TCP 54321, sempre in uscita (comodo dietro NAT).
Quali apparati possono fare cosa
| Ruolo | Cosa serve | Architetture |
|---|---|---|
| Server (il controller) | pacchetto cmr installato | arm, arm64, x86 |
| Client (il gestito) | niente, è nel base da 7.26 | arm, arm64, x86, mmips |
Restano fuori le piattaforme più piccole/vecchie (smips, PowerPC): né server né client. Il client arriva anche su mmips; il server no, vuole arm/arm64/x86.
Che server mettere, per andare bene
Il server tiene l'inventario di tutta la flotta, cifra una sessione TLS per ogni client, raccoglie gli output degli script e — quando aggiorni — fa anche da cache dei pacchetti (vedi oltre). Più client e più funzioni usi, più CPU/RAM/disco vuole. In pratica:
- CPU: conta il single-thread. Per flotte serie prendi un apparato x86 (un CHR su mini-PC/VM, o un router x86) o un arm64 di fascia alta, non un arm entry-level.
- RAM: l'inventario e le sessioni crescono coi client — stai largo (≥1–2 GB sul server per flotte grandi).
- Disco: la cache dei pacchetti di upgrade occupa spazio (un set
.npkper architettura) → serve storage, non la sola NAND da pochi MB.
Un CHR su una VM con qualche core e un paio di GB è il server "da laboratorio/produzione piccola" ideale: x86, risorse elastiche, niente radio da sprecare.
Come si trovano server e client (tre vie, provate a pacchetto)
Qui c'è una sorpresa gradita e un paio di miti da sfatare. Un client arriva al controller in questi modi:
E lo si legge a pacchetto. Ecco l'annuncio del controller catturato sul segmento (MNDP, UDP 5678 broadcast), decodificato campo per campo:
IP 10.0.0.1.5678 > 255.255.255.255.5678 UDP len 153 # broadcast, in chiaro
TLV 1 MAC ............. AA:BB:CC:00:11:01
TLV 5 identity ........ cmr-srv
TLV 7 version ......... 7.26beta1 2026-10-01 13:29:47
TLV 8 platform ........ MikroTik
TLV 11 software-id ..... glwRS+Ru+AG
TLV 12 board ........... (apparato)
TLV 16 interface ....... ether1
TLV 17 IPv4 ............ 10.0.0.1
TLV 15 IPv6 ............ fe80::...
TLV 18 (NUOVO 7.26) .... 0x02 <── marcatore CMR
TLV 19 (NUOVO 7.26) .... 0x79 <── marcatore CMRI campi da 1 a 17 sono il solito MNDP (identità, versione, scheda, indirizzi). I due TLV nuovi della 7.26 — tipo 18 e 19 (i byte grezzi 0x02 e 0x79) — nell'MNDP classico non esistono: sono il cartello «qui c'è un controller CMR», ciò che permette al client di riconoscere il server sul segmento e auto-adottarsi. A conti fatti, nel pacchetto sono l'unica cosa che sembra segnalare in automatico «io sono un controller» al client. E tutto — identità e indirizzo del controller compresi — viaggia in chiaro: lo vede chiunque annusi la LAN (il canale di controllo sulla 54321 resta invece TLS).
/cmr/client set controller-addresses=cmr.tuodominio.tld
/cmr/client set controller-addresses=10.0.0.1,10.0.0.2 # listaE RoMON? Verrebbe da pensarci — è l'overlay di management di MikroTik che attraversa i segmenti L2 dove l'MNDP si ferma. Ma no: il controllo CMR è IP/TLS e vuole raggiungibilità IP (routing/VPN), RoMON non lo trasporta. Il dettaglio in fondo, nelle FAQ.
Nota fiduciosa: che manchi la discovery via DHCP (lo "option 43/138" stile UniFi/Omada) è un vuoto di gioventù — la richiesta è già nei pacchetti del client. Confidiamo che MikroTik la attivi: sarebbe il tassello per i rami remoti.
Il pairing: il device arriva, tu lo approvi
Un client che si presenta non è automaticamente gestito: il server lo vede «in attesa di pairing» — esattamente il modello "pending → approve" dei controller commerciali. Tre modalità:
- none — approvazione automatica. Comoda in LAN fidata, ma vuol dire «chi si connette viene adottato»: da evitare su reti esposte.
- password — segreto condiviso: il device prova di essere lui.
- confirm — serve un'azione sul device: approvazione a due mani (il più sicuro).
Il legame è crittografico e per-identità: ogni nodo ha un suo local-id, e il client memorizza l'identità del controller a cui si è pairato. Conseguenza utile: un controller-canaglia con identità diversa non dirotta un client già adottato.
Controller o provisioner? La domanda che tutti fanno sul WiFi
È la verifica che interessa a chi viene da UniFi/Omada/Cambium. Abbiamo agganciato alla flotta un apparato reale con due radio e guardato cosa espone davvero il provisioning WiFi del CMR. La regola di provisioning, per intero:
/cmr/wifi/print
labels=ap ssid=DojoWiFi security.passphrase=*** security.authentication-types=wpa2-psk
La regola di base porta SSID + sicurezza + label. Si può provisionare anche un canale fisso (c'è una scheda Radio Configuration), e la Dashboard mostra perfino l'occupazione per frequenza — quanti AP su ciascun canale, a 2/5/6 GHz. Quindi i dati radio ci sono e sono persino visualizzati.
Quello che manca è l'azione. CMR mostra lo spettro e ti lascia fissare un canale, ma non c'è il controller "vivo" che ascolta le interferenze e sposta il canale, abbassa la potenza, fa band-steering coordinato tra AP da solo. In una parola: provisioning e monitoraggio sì, RRM no. L'auto-canale esiste a livello RouterOS, ma è una scelta una-tantum all'avvio, non un'ottimizzazione continua di flotta. L'hardware saprebbe farlo (le radio dichiarano scansione spettrale e cambio-canale al volo): manca l'orchestrazione che le guidi.
Nota fiduciosa: è beta. Il salto sul management c'è; l'RRM radio no. Confidiamo che MikroTik aggiunga l'ottimizzazione vera. E intanto — visto che i dati (scan, monitor) e il canale di comando (run-script) ci sono già — quel pezzo si può costruire sopra CMR: ne parliamo nel seguito.
Cosa ci fai davvero
Non è solo CLI: in WinBox/Webfig c'è un menu CMR dedicato con Dashboard (device online/pairati, risorse, spettro WiFi), Devices (l'inventario con i tool Pair/Script/Upgrade/Reboot), Alerts, Ports (Tx/Rx e PoE porta per porta di tutta la flotta), Topology, Traffic, VLAN Rules e WiFi. Sotto, però, tutto è anche API/REST — ed è lì che si vede cosa fa davvero.
Raggruppi per etichette
Ogni operazione seleziona i device per label, con una piccola algebra: OR (office,lab), AND (office,+ap), esclusione (office,-ap), jolly (all, all,-core).
Lanci uno script su tutto il gruppo, e ti torna l'output
È la funzione-principe. Un comando, N device, output raccolto per ciascuno:
/cmr/device/run-script labels=office \
script=":put ([/system/identity/get name].\" up \".[/system/resource/get uptime])"
device=cmr-c2@... status=success output=cmr-c2 up 02h09m
device=cmr-c3@... status=success output=cmr-c3 up 02h09mrun-script ha permessi read, write, test, reboot — e basta. Creare un utente — o cambiargli la password — da remoto fallisce, e anche avviare lo sniffer è bloccato. L'output vero del run-script:
run-script … script="/user/set [find name=admin] password=…"
device=cmr-c2@… status=failed
output=not enough permissions (9) (/user/set; line 1)
run-script … script="/tool/sniffer/start"
device=cmr-c2@… status=failed
output=not enough permissions (9) (/tool/sniffer/start; line 1)policy. Però può leggere e scrivere config e riavviare — e questo basta per fare danni (vedi "raggio dell'esplosione").Allarmi — con log e webhook HTTP nativo
CMR arriva con allarmi di default (CPU>95%, memoria>80%, device disconnesso, aggiornamento disponibile, device non pairato che si connette, device riavviato) e ne aggiungi di tuoi. Le azioni provate sul ferro:
- Log sul controller:
action.log="…"+action.log-topics=…(con placeholder[device],[cpu-usage]…). - Webhook HTTP — nativo:
action.http-url=…+action.http-method=(get/post/put/…) +action.http-body=…. Quando l'allarme scatta, CMR chiama l'URL.
Non ci sono azioni "email" o "telegram" dirette — ma non servono: il webhook le copre tutte. Un POST al webhook di Telegram/Slack/Discord, o a un tuo n8n/Node-RED, e l'allarme arriva dove vuoi. L'abbiamo fatto scattare: un device non-pairato che si connette → riga in log device NON pairato connesso; è di fatto un «qualcuno ha attaccato un apparato non gestito alla mia flotta».
Upgrade orchestrati, e la "R" di Repository
Regole di aggiornamento per gruppo, con finestra oraria e canale (stable, long-term, testing, development): c'è già una regola default su stable. E qui si capisce la R di CMR: il server fa da repository dei pacchetti — scarica i .npk dal canale scelto, li cachea (cartella cmrpkgs, con tetto configurabile) e li distribuisce ai client. Una scaricata, tanti apparati: perfetto per una flotta dietro un'unica uscita. Nota: cachea tutti i pacchetti che un device ha (routeros + gli extra come container, wireless…), per architettura — ecco perché l'upgrade è "di tutto il device". Non si fissa una versione precisa, si segue il canale.
La "R" è solo la cache dei pacchetti: non è un repository di log né di backup (vedi FAQ).
Costruisci la tua interfaccia: API, REST, scripting, webhook
Il bello di CMR è che non ti chiude: tutti i suoi dati sono accessibili e componibili. Provato sul ferro — la REST API serve l'inventario in JSON:
GET /rest/cmr/device → [ {".id":"*3","identity":"cmr-c2","board":"CHR",
"version":"7.26beta1","connected":"true", … }, … ]
GET /rest/cmr/alert → [ … le tue alert in JSON … ]Tre superfici per leggere/scrivere — API binaria, REST (JSON su HTTP/S), scripting on-box — più il webhook per spingere eventi fuori. Con questi mattoni ti fai la dashboard che vuoi, colleghi CMR al monitoraggio che già hai (Grafana/Zabbix leggono la REST), o automatizzi reazioni. Il controller nativo ti dà i dati; l'interfaccia la decidi tu.
Sicurezza (provata a pacchetto)
run-script: record TLS 1.2 (17 03 03, Application Data), payload ad alta entropia. Nessun pezzo in chiaro di script o output sul filo.In più: porta fissa 54321 (non si cambia), fiducia legata all'identità del controller (il pairing), nessun cert-pinning configurabile (la fiducia è la chiave di pairing, stile TOFU all'adozione). Esposizioni da tenere a mente: (1) servizio TLS beta = superficie pre-auth non ancora battagliata; (2) adozione-canaglia se usi pairing=none su un server esposto; (3) la discovery in chiaro (metadati, non controllo). Regola: non esporre la 54321 nuda su Internet — meglio dietro VPN (i client puntano all'IP privato), o esposta solo con pairing=confirm + allow-list sugli IP sorgente. Nessuna VPN integrata nel CMR: il suo canale è un tunnel TLS di gestione, non una VPN dati.
La discovery si può falsificare — ma il default ti salva
L'MNDP non è autenticato, quindi i due byte-marcatore si possono forgiare. L'abbiamo provato: con un piccolo annunciatore MNDP su misura (marcatori CMR + un IP a scelta) un client vergine ha provato a collegarsi all'indirizzo annunciato — anche a un IP pubblico (un indirizzo di Cloudflare): sulla 54321 è partito il SYN verso quell'IP, con controller-addresses rimasto vuoto. Tradotto: chi è sullo stesso segmento L2 può spingere un client abilitato ma non ancora pairato verso un controller a sua scelta (potenziale adozione-canaglia, se quel controller accetta il pairing).
# annuncio MNDP forgiato (marcatori CMR + IP a scelta) → il client vergine tenta la 54321:
IP <client> > 10.11.12.13.54321: Flags [S] # un IP privato a piacere
IP <client> > 1.1.1.1.54321: Flags [S] # …o persino un IP PUBBLICO
# controller-addresses del client: VUOTO (l'indirizzo arriva solo dall'annuncio forgiato)Due cose però ridimensionano il rischio — e sono anche il modo di proteggersi:
- Il client CMR è spento di fabbrica. Su un RouterOS 7.26 appena installato
/cmr/clientèenabled=no: un apparato che non ha mai toccato CMR non reagisce all'annuncio. Il rischio esiste solo se il client è stato acceso. - Un device già pairato è legato all'identità del suo controller (
local-id): un annuncio con identità diversa non lo dirotta.
Hardening (provato): se non usi CMR, tieni il client spento — /cmr/client set enabled=no (con il client disabilitato, zero tentativi anche sotto spoofing). Se lo usi, restringi la neighbor-discovery alle sole interfacce fidate e adotta i device con pairing=confirm, mai none.
Nota fiduciosa: la discovery non autenticata è un tratto di gioventù — confidiamo che MikroTik firmi/autentichi l'annuncio, così lo spoofing non morde più. È beta: ha tutto il tempo per sistemarlo.
Il rovescio: il raggio dell'esplosione
Tutta la comodità ha un prezzo: da un singolo nodo si colpisce l'intera flotta. labels=all è un grilletto:
/cmr/device/run-script labels=all script=... # gira su OGNI device
/cmr/device/upgrade labels=all ... # aggiorna OGNI device
/cmr/device/reboot labels=all # riavvia OGNI deviceUn errore di battitura o un server compromesso si propagano all'istante. La gabbia dei permessi evita il disastro "utenti/policy", ma scrivere config + riavviare + schedulare upgrade su tutto basta a mettere giù una rete da un punto solo. Proteggi la 54321; non usare pairing=none dove chiunque può presentarsi.
«Ma se il router è già configurato?»
Domanda giusta, risposta provata. Su un client con config vera (bridge mybr, VLAN, indirizzo) l'abbiamo pairato, gestito e persino puntato con una regola CMR. Esito:
bridge mybr → intatto (comment="config-utente", dynamic=false)
vlan v100 → intatta
indirizzo → intatto
oggetti aggiunti da CMR al device: 0Nota fiduciosa: che il provisioning non adotti ancora la config esistente è un limite di gioventù — confidiamo maturi in fretta.
E se cade il controller?
Provato: con il server spento, i device continuano a funzionare — traffico, IP e config loro intatti; la config già provisionata resta. Perdi solo la regia centrale (inventario/script/alert/upgrade) finché non torna. E al ritorno i client si riconnettono da soli e restano pairati. CMR è un piano di gestione, non sta nel percorso dati: cade il controller, la rete non se ne accorge.
Ridondanza e gerarchia
HA master/slave con sincronizzazione? No, non in questa beta (redundancy non esiste; ogni server ha identità e DB di pairing propri). L'unico mattone di ridondanza: il client accetta più controller-addresses → puoi fare uno standby "a freddo" (pre-pairi i device anche a un secondo server e metti entrambi gli indirizzi). Non è failover automatico con stato condiviso.
Gerarchia di controller? Sì, come impilamento. Un nodo può essere server e client insieme: un gateway di ramo fa da server per i suoi AP locali (auto-adozione MNDP) e da client verso un CMR master. Ma il master vede quel ramo come un solo device, non i suoi AP: è una piramide di controller, non una vista unica della flotta. Per i rami remoti, inoltre, non c'è modalità relay/proxy: ogni AP deve raggiungere il CMR via IP (routing/VPN del gateway), con l'indirizzo impostato.
Nota fiduciosa: le primitive (nodo server+client, controller-addresses multipli) ci sono. Un HA vero e un relay di ramo sarebbero l'evoluzione naturale.
FAQ rapide (tutte verificate)
cmr; un CHR su VM è però la scelta comoda (x86, risorse elastiche).controller-addresses accetta hostname → DDNS/IP Cloud vanno. Attenzione: IP Cloud non ha settaggi nuovi legati a CMR, resta il solito DDNS da mettere a mano.mangle action=sniff-tzsp (è un write sul firewall) che specchia i pacchetti a un collector/container. Il CMR non ha un visore di cattura./user/set password= via run-script fallisce (not enough permissions (9)). E nemmeno la scorciatoia regge: se deployi uno script chiedendogli policy alta, RouterOS gliela taglia ai soli permessi della gabbia (reboot;read;write;test) → lo script gira ma il cambio password fallisce comunque. Non c'è una policy "CMR" nei user-group da concedere. È un bene per la sicurezza (un CMR compromesso non tocca le credenziali), ma oggi la rotazione password di flotta con CMR non si fa: va fatta per altra via (chiavi SSH + automazione API/Ansible). Nota fiduciosa: è proprio il genere di funzione che manca — confidiamo che MikroTik aggiunga una rotazione credenziali sicura.