Fähigkeiten routeros-qemu-chr
📦

routeros-qemu-chr

Niedriges Risiko ⚙️ Externe Befehle🌐 Netzwerkzugriff📁 Dateisystemzugriff

MikroTik RouterOS CHR in QEMU ausführen

MikroTik RouterOS CHR bietet einen voll funktionsfähigen virtuellen Router für Tests und Entwicklung, aber die Einrichtung erfordert die Navigation durch QEMU-Optionen, VirtIO-Treiber und Firmware-Konfigurationen. Diese Skill bietet vollständige Anleitung für die Ausführung von CHR mit Beschleunigung, korrekter VirtIO-Einrichtung und REST-API-Integration.

Unterstützt: Claude Codex Code(CC)
⚠️ 63 Schlecht
1

Die Skill-ZIP herunterladen

2

In Claude hochladen

Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen

3

Einschalten und loslegen

Teste es

Verwendung von "routeros-qemu-chr". CHR mit KVM-Beschleunigung und REST-API auf Port 9180 booten

Erwartetes Ergebnis:

QEMU startet mit Hardware-Beschleunigung. RouterOS bootet in ca. 5 Sekunden. HTTP-200-Antwort von http://127.0.0.1:9180/ bestätigt die Bereitschaft. REST-API unter http://127.0.0.1:9180/rest/ mit Admin-Anmeldedaten zugänglich.

Verwendung von "routeros-qemu-chr". KVM auf GitHub Actions Ubuntu-Runner aktivieren

Erwartetes Ergebnis:

udev-Regel erstellt unter /etc/udev/rules.d/99-kvm4all.rules. KVM-Geräteberechtigungen auf 0666 aktualisiert. QEMU öffnet /dev/kvm erfolgreich für Hardware-Beschleunigung. Bootzeit von ca. 30s auf ca. 5s reduziert.

Verwendung von "routeros-qemu-chr". Port-Weiterleitung für RouterOS-Dienste konfigurieren

Erwartetes Ergebnis:

Host-Ports zugeordnet: 9180→80 (REST-API), 9122→22 (SSH), 9728→8728 (API), 9729→8729 (API-SSL), 9291→8291 (WinBox). Dienste über Localhost-Ports vom Host aus zugänglich.

Sicherheitsaudit

Niedriges Risiko
v2 • 4/16/2026

Documentation and reference skill for running RouterOS CHR in QEMU. Static analysis flagged 343 patterns, but evaluation reveals these are false positives: shell backtick notation in markdown code examples (not execution), sudo in GitHub Actions CI (expected), MD5 references in kernel history docs (not actual usage), and legitimate acceleration detection commands. All network access targets MikroTik infrastructure for downloading CHR images. Risk level set to LOW due to external command patterns in documentation examples, but no actual malicious code present.

5
Gescannte Dateien
794
Analysierte Zeilen
12
befunde
2
Gesamtzahl Audits

Probleme mit hohem Risiko (4)

SKILL.md:16-316references/chr-licensing.md:25-71references/github-actions-ci.md:7-254references/known-issues.md:5-81references/virtio-drivers.md:9-53
Documentation Shell Examples Misidentified as Execution
Static scanner flagged 264 instances of Ruby/shell backtick notation. These are markdown code blocks showing shell command syntax, not actual command execution. Files are documentation with command examples.
references/github-actions-ci.md:34-48
sudo Commands in GitHub Actions CI (Expected Behavior)
GitHub Actions workflow uses sudo for package installation (apt-get install). This is standard CI/CD practice, not privilege escalation risk.
references/github-actions-ci.md:103references/known-issues.md:55-62
nohup for Background QEMU Process (Legitimate Use)
nohup is used to run QEMU in background during CI testing. This is standard practice for running VMs in CI environments.
SKILL.md:271
Base64 HTTP Basic Auth (Standard Practice)
Static scanner flagged btoa('admin:') as weak crypto. This is standard HTTP Basic Auth encoding, not cryptographic weakness.
Probleme mit mittlerem Risiko (3)
SKILL.md:32-38references/github-actions-ci.md:71-72references/chr-licensing.md:36
Network Access to External URLs
Skill downloads CHR images from MikroTik infrastructure. URLs point to download.mikrotik.com and cdn.mikrotik.com for official RouterOS images.
references/github-actions-ci.md:11SKILL.md:69
Device File Access for Virtualization
/dev/kvm access for KVM acceleration detection. This is standard practice for virtualization tooling.
references/github-actions-ci.md:110-238SKILL.md:104-148
Temp Directory Access
/tmp used for QEMU vars files, serial sockets, and log files. Standard temp file usage for VM management.
Probleme mit niedrigem Risiko (2)
SKILL.md:110-270references/github-actions-ci.md:130-232
Hardcoded IP Addresses (Localhost)
127.0.0.1 used for RouterOS REST API and port forwarding. Standard localhost addressing.
SKILL.md:24-45references/known-issues.md:35
System Information Commands (Acceleration Detection)
uname, sysctl, and stat commands used for platform detection. Standard virtualization tooling practice.

Risikofaktoren

⚙️ Externe Befehle (3)
SKILL.md:66-83 references/github-actions-ci.md:34-48 references/github-actions-ci.md:103
🌐 Netzwerkzugriff (2)
SKILL.md:32-38 references/github-actions-ci.md:71-72
📁 Dateisystemzugriff (2)
SKILL.md:69 references/github-actions-ci.md:11
Auditiert von: claude Audit-Verlauf anzeigen →

Qualitätsbewertung

45
Architektur
100
Wartbarkeit
87
Inhalt
32
Community
40
Sicherheit
100
Spezifikationskonformität

Was du bauen kannst

Automatisierte RouterOS REST-API-Tests in CI

RouterOS CHR als CI-Test-Fixture ausführen, um REST-API-Aufrufe zu validieren, RAML-Schemata zu generieren und /app-YAML-Konfigurationen ohne manuelle Router-Einrichtung zu testen.

Entwicklungs- und Lernumgebung

Eine Free-Lizenz-CHR-Instanz booten, um RouterOS-Funktionen zu erkunden, Firewall-Regeln zu testen, Bridging zu experimentieren und Netzwerkkonzepte ohne Produktionshardware zu erlernen.

Tests für mehrere Architekturen

RouterOS-Konfigurationen auf sowohl x86_64- als auch aarch64-Architekturen mit QEMU testen, unter Verwendung geeigneter Firmware (SeaBIOS für x86, UEFI für ARM) und Beschleunigungsoptionen.

Probiere diese Prompts

Grundlegende CHR-Einrichtung 
Helfen Sie mir, RouterOS CHR in QEMU einzurichten. Ich muss das neueste stabile Image herunterladen und es mit KVM-Beschleunigung und Port 9180 für die REST-API booten.
GitHub Actions CI-Integration 
Schreiben Sie einen GitHub Actions Workflow, der RouterOS CHR herunterlädt, es mit KVM bootet, wenn verfügbar (Fallback auf TCG), auf den Boot wartet und dann REST-API-Tests ausführt.
ARM64 UEFI-Startkonfiguration 
QEMU konfigurieren, um RouterOS CHR aarch64 auf macOS Apple Silicon zu booten. Einschließlich der UEFI-pflash-Einrichtung und expliziten virtio-blk-pci-Gerätekonfiguration.
Boot-Fehler beheben 
RouterOS CHR bootet nicht mit einem leeren Bildschirm. Das Festplattenimage verwendet if=virtio auf aarch64. Was könnte falsch sein und wie behebe ich es?

Bewährte Verfahren

  • Verwenden Sie explizites -device virtio-blk-pci anstelle von if=virtio-Abkürzung auf aarch64, um die MMIO-Falle zu vermeiden, die lautlose Boot-Fehler verursacht
  • Überprüfen Sie die Schreibbarkeit von /dev/kvm (nicht nur die Existenz), bevor Sie KVM aktivieren, und fallen Sie immer graceful auf TCG zurück, falls KVM nicht verfügbar ist
  • Verwenden Sie Port-Weiterleitungsmuster wie tcp::9180-:80 anstatt Localhost-IPs fest zu kodieren, um die Konfiguration portabel und wiederverwendbar zu machen

Vermeiden

  • Verwenden Sie if=virtio nicht auf aarch64-Architektur - dies löst zu MMIO auf, was RouterOS nicht unterstützt und lautlose Boot-Fehler verursacht
  • Überspringen Sie die KVM-Berechtigungsprüfung nicht - /dev/kvm existiert möglicherweise, ist aber nicht lesbar, und QEMU fällt bei Berechtigungsfehlern nicht lautlos auf TCG zurück
  • Verwenden Sie git pull && git push nicht in gleichzeitigen CI-Builds - verwenden Sie das Retry-with-Rebase-Muster, um Push-Ablehnungen aus Race Conditions zu vermeiden

Häufig gestellte Fragen

Was ist das Geschwindigkeitslimit bei der kostenlosen CHR-Lizenz?
Die kostenlose CHR-Lizenz begrenzt den Interface-Durchsatz auf 1 Mbps. REST-API-Aufrufe, SSH, WinBox und WebFig-Zugriff sind nicht betroffen. Dieses Limit gilt nur für die tatsächliche Datenweiterleitung zwischen Interfaces.
Warum funktioniert der QEMU Guest Agent nicht mit HVF-Beschleunigung?
Der RouterOS QGA-Daemon startet nur, wenn er einen KVM-Hypervisor über CPUID erkennt. Unter HVF (macOS) oder TCG (Software-Emulation) gibt CPUID 0x40000000 keine KVM-Herstellerzeichenkette zurück, sodass der Daemon nie startet. Verwenden Sie Linux mit KVM für QGA-Tests.
Wie wähle ich zwischen SeaBIOS und UEFI für den CHR-Boot?
Verwenden Sie SeaBIOS für x86_64 (Standard, schnellster Boot). Verwenden Sie UEFI für aarch64 ARM-Architektur. Auf x86_64 kann nur SeaBIOS die proprietäre Boot-Partition booten; OVMF kann sie nicht lesen.
Warum ist mein aarch64 CHR beim Booten mit if=virtio hängengeblieben?
Auf aarch64 virt-Maschine löst if=virtio den MMIO-Transport auf. RouterOS hat virtio_pci, aber keinen virtio_mmio-Treiber, sodass der Kernel lautlos hängt. Verwenden Sie immer explizites -device virtio-blk-pci auf aarch64.
Kann ich mehrere CHR-Instanzen gleichzeitig ausführen?
Ja. Verwenden Sie eindeutige Host-Ports für jede Instanz (9180, 9181, 9182 für REST-API usw.). Jede Instanz benötigt ein eigenes Festplattenimage und PID-Tracking für die Bereinigung.
Welche Beschleunigungsmethode sollte ich verwenden?
Verwenden Sie KVM auf Linux, wenn Host-/Gast-Architekturen übereinstimmen. Verwenden Sie HVF auf macOS Apple Silicon für aarch64-Gäste. Verwenden Sie TCG als Fallback auf allen Plattformen, wenn Hardware-Beschleunigung nicht verfügbar ist.

Entwicklerdetails

Autor

tikoci

Lizenz

MIT

Repository

https://github.com/tikoci/routeros-skills/tree/main/routeros-qemu-chr

Ref

main

Dateistruktur

📁 references/

📄 chr-licensing.md

📄 github-actions-ci.md

📄 known-issues.md

📄 virtio-drivers.md

📄 SKILL.md