Grounding RouterOS with quickchr

SkillDev tools

Ground RouterOS config/scripts/API code against a REAL router using quickchr (@tikoci/quickchr) — a CLI + Bun/TS library that downloads, boots, and manages MikroTik CHR VMs on QEMU. Use when: validating generated RouterOS config or scripts against real RouterOS before trusting them; spinning up a disposable CHR for REST/CLI/API iteration; writing integration/lab tests against CHR; needing host↔guest networking for a CHR (port-forward, L2/MNDP capture, guest→host UDP); driving an external RouterOS tool against a live CHR. For raw QEMU/CHR boot mechanics (VirtIO, UEFI vs SeaBIOS, acceleration) without quickchr, use routeros-qemu-chr instead.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Grounding RouterOS with quickchr skill

What this skill tells your AI

The instructions your AI receives, as published by tikoci/routeros-skills in routeros-quickchr/SKILL.md and read by ahel’s review.

What this is for

The reliable way to know whether a RouterOS config, script, or API call actually works is to run it against real RouterOS — not to guess from docs. quickchr (@tikoci/quickchr, npm, MIT, public) makes that a few lines: it downloads a MikroTik CHR (Cloud Hosted Router) image, boots it under QEMU, provisions it, and hands you a REST/SSH/exec handle. The free CHR license (1 Mbps, no signup) is enough for config validation, API iteration, and test grounding.

Reach for quickchr when you want to apply config and read it back, iterate on REST/scripting against a live box, or run integration tests against CHR.

Don't reach for it when you only need documentation (use the rosetta MCP / the routeros-fundamentals skill), or you're flashing physical hardware (use the routeros-netinstall skill). For raw QEMU boot internals without the quickchr wrapper, see the routeros-qemu-chr skill.

The grounding loop (core pattern)

import { QuickCHR } from "@tikoci/quickchr";

const chr = await QuickCHR.start({ name: "lab", channel: "stable" });
// start() resolves REST-READY — provisioning is already done. No second wait needed
// in normal background/library use; waitForBoot() is only a belt-and-suspenders check.

await chr.exec("/ip/firewall/address-list/add list=blocked address=10.9.9.9");
const list = await chr.rest("/ip/firewall/address-list");   // structured read-back
// assert the entry is there → your config is grounded against real RouterOS

await chr.remove();   // tear down

exec() runs a CLI command (config writes, scripts) and returns { output, via }; rest() does a REST call and returns parsed JSON. Worked, runnable version: examples/grounding/. Minimal boot-and-read smoke test: examples/quickstart/. All examples are runnable bun run scripts (grounding/ is the one bun:test); the full set + coverage map is in examples/COVERAGE.md.

Tip — re-run safety. Give each run a unique machine name and assert on values carrying a per-run nonce, so a stale machine from an interrupted run can't make a later run pass falsely.

Key entry points

Pointers, not duplicated signatures — the authoritative, versioned reference is the quickchr MANUAL.md and the JSDoc in src/lib/types.ts. See also references/quickchr-api.md in this skill.

NeedSurface
Boot / create a machineQuickCHR.start(opts) → REST-ready ChrInstance
Pick RouterOSchannel (stable/long-term/testing/development) or version ("7.23.1")
Architecturearch:"x86" or "arm64"
Managed login vs open adminsecureLogin: true (managed user, real password) / false
Run a CLI commandinstance.exec(cmd, opts?)
REST callinstance.rest(path, init?)
Move filesinstance.upload(local, remote?) / instance.download(remote, local)
Add a packageinstance.installPackage(name) (downloads + reboots; returns installed names)
Custom port-forwardsextraPorts / CLI --forward (see Networking)
Extra NICsnetworks / CLI --add-network (see Networking)
Connection surface for a child processinstance.subprocessEnv() / instance.descriptor()
Snapshotsinstance.snapshot(...)
Tear downinstance.remove() / instance.stop() / instance.destroy()

The same two knobs exist on the CLI and the library:

CLILibrary (StartOptions)
--forward <spec> (repeatable)extraPorts: PortMapping[]
--add-network <spec> (repeatable)networks: NetworkSpecifier[]

CLI without installing: bunx @tikoci/quickchr <cmd> (e.g. add, start, exec, list, inspect, env, networks, logs). Library dependency patterns (npm / file: / bun link): examples/README.md.

Networking — which mechanism for which traffic

The default user (SLIRP) NIC handles management (REST/SSH/WinBox via host-port forward) and is all most grounding needs. Reach past it only for these shapes (full by-goal guide: docs/networking-recipes.md):

You want…DirectionMechanism
Reach a guest TCP/UDP service (REST, SSH, WinBox, SNMP, container port)host → guestuser NIC + hostfwd (--forward / extraPorts)
Reach a guest service on many/dynamic ports (e.g. btest data ports)host → guesthostfwd range (--forward name:9200-9210:2000-2010/udp)
Receive UDP the guest sends (syslog, NetFlow, TZSP, a server replying)guest → hostguest sends to gateway 10.0.2.2:<port>; host binds an unconnected socket — no forward
Receive guest L2 frames / broadcasts (MNDP, MAC-Telnet, raw Ethernet)guest ↔ hostsocket-connect L2 NIC (host runs a TCP server)
L2 link between two VMsVM ↔ VMsocket::<name> named pair
Real LAN presence / DHCP from the hostfull L3shared or bridged:<iface>

Two non-obvious points worth keeping:

  • guest → host UDP needs no forward. The gateway 10.0.2.2 is the host from inside the VM. A datagram the guest sends to 10.0.2.2:<port> reaches a host socket bound on loopback — but leave that host socket unconnected (recvfrom): SLIRP relays it from a rewritten source (127.0.0.1:<ephemeral>), so a connect()-ed socket filters it out. instance.tzspGatewayIp (10.0.2.2) and instance.captureInterface (lo0/any) expose the constants. Runnable: examples/udp-gateway/.
  • user terminates Layer 2. For MNDP/MAC-Telnet/broadcasts, add a socket-connect NIC — the host runs a TCP server, QEMU streams length-prefixed guest frames to it (rootless, loopback-only, cross-platform). Recipe + wire detail: docs/mndp.md; examples/mndp/. Keep user first (ether1) in any multi-NIC config — RouterOS only auto-DHCPs ether1, and hostfwd needs the guest's 10.0.2.15.

Driving an external tool against a live CHR

To point a separate process at a running CHR (a schema extractor, a protocol suite, a CLI), use the stable connection surface instead of reading machine.json:

const env = await chr.subprocessEnv();   // URLBASE, BASICAUTH, QUICKCHR_*
Bun.spawn(["my-tool"], { env: { ...process.env, ...env } });

BASICAUTH / QUICKCHR_AUTH are the raw user:password string (not a header) — base64-encode for HTTP Basic: Authorization: Basic ${btoa(env.BASICAUTH)}. URLBASE already includes the /rest base. descriptor() gives the same surface as a structured { urls, auth, ports, status, version } record. Both are secret-bearing — pass via env, don't log. Always check a machine is running before using stored ports. Runnable: examples/harness/.

Grounding gotchas & known limitations

  • Provisioning floor: managed login, package install, and exec-write provisioning need RouterOS 7.20.8+; older 7.x is boot-only.
  • QGA (--via=qga) needs KVM — RouterOS only starts the guest agent under a KVM hypervisor, so it's unavailable under HVF (macOS) and TCG. Use REST/exec.
  • socket-mcast is broken on macOS (QEMU sets only SO_REUSEADDR); use socket-connect for point-to-point / host capture. Works on Linux.
  • Cross-arch TCG x86-on-arm64 is not viable (x86 I/O emulation is too slow); aarch64-on-x86 is fine. KVM/HVF require host/guest arch match.
  • Free CHR is rate-limited to 1 Mbps — fine for config/API grounding, not throughput tests. A free 60-day trial removes the limit.

Flakes: these examples and recipes are grounded on real CHR runs. If you hit a non-deterministic failure (a boot that wedges, an intermittent REST error), re-run once; if it persists, please file an issue with qemu.log at https://github.com/tikoci/quickchr/issues rather than working around it silently.

Authoritative docs & related skills

  • quickchr repo: README · MANUAL · DESIGN · docs/ · examples/
  • references/quickchr-api.md — fuller API map (start options, ChrInstance methods/properties, port layout, error codes).
  • routeros-qemu-chr — raw QEMU/CHR boot internals (VirtIO, UEFI/SeaBIOS, acceleration) underneath quickchr.
  • routeros-fundamentals — RouterOS CLI/REST/scripting once the CHR is up.
  • routeros-sniffer / routeros-mndp — TZSP capture and MNDP wire format (the gateway-UDP and socket-connect recipes above feed these).

Signals

GitHub stars
59
Forks
14
Last commit
Jul 2026
Advanced
Catalog kind
skill
Gateway key
routeros-quickchr
Source
github.com/tikoci/routeros-skills