Habilidades routeros-qemu-chr
📦

routeros-qemu-chr

Riesgo bajo ⚙️ Comandos externos🌐 Acceso a red📁 Acceso al sistema de archivos

Ejecutar MikroTik RouterOS CHR en QEMU

MikroTik RouterOS CHR proporciona un router virtual completo para pruebas y desarrollo, pero la configuración requiere navegar por las opciones de QEMU, los controladores VirtIO y las configuraciones de firmware. Esta habilidad proporciona orientación completa para ejecutar CHR con aceleración, configuración adecuada de VirtIO e integración con la API REST.

Soporta: Claude Codex Code(CC)
⚠️ 63 Deficiente
1

Descargar el ZIP de la skill

2

Subir en Claude

Ve a Configuración → Capacidades → Skills → Subir skill

3

Activa y empieza a usar

Pruébalo

Usando "routeros-qemu-chr". Boot CHR with KVM acceleration and REST API on port 9180

Resultado esperado:

QEMU se inicia con aceleración de hardware. RouterOS arranca en ~5 segundos. Respuesta HTTP 200 de http://127.0.0.1:9180/ confirma disponibilidad. API REST accesible en http://127.0.0.1:9180/rest/ con credenciales admin.

Usando "routeros-qemu-chr". Enable KVM on GitHub Actions Ubuntu runner

Resultado esperado:

Regla udev creada en /etc/udev/rules.d/99-kvm4all.rules. Permisos de dispositivo KVM actualizados a 0666. QEMU abre /dev/kvm exitosamente para aceleración de hardware. Tiempo de arranque reducido de ~30s a ~5s.

Usando "routeros-qemu-chr". Configure port forwarding for RouterOS services

Resultado esperado:

Puertos de host mapeados: 9180→80 (API REST), 9122→22 (SSH), 9728→8728 (API), 9729→8729 (API-SSL), 9291→8291 (WinBox). Servicios accesibles desde el host mediante puertos localhost.

Auditoría de seguridad

Riesgo bajo
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
Archivos escaneados
794
Líneas analizadas
12
hallazgos
2
Auditorías totales

Problemas de riesgo alto (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.
Problemas de riesgo medio (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.
Problemas de riesgo bajo (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.

Factores de riesgo

⚙️ Comandos externos (3)
SKILL.md:66-83 references/github-actions-ci.md:34-48 references/github-actions-ci.md:103
🌐 Acceso a red (2)
SKILL.md:32-38 references/github-actions-ci.md:71-72
📁 Acceso al sistema de archivos (2)
SKILL.md:69 references/github-actions-ci.md:11
Auditado por: claude Ver historial de auditorías →

Puntuación de calidad

45
Arquitectura
100
Mantenibilidad
87
Contenido
32
Comunidad
40
Seguridad
100
Cumplimiento de la especificación

Lo que puedes crear

Pruebas automatizadas de API REST de RouterOS en CI

Ejecutar RouterOS CHR como fixture de prueba en CI para validar llamadas a la API REST, generar esquemas RAML y probar configuraciones YAML de /app sin configuración manual del router.

Entorno de desarrollo y aprendizaje

Iniciar una instancia CHR con licencia gratuita para explorar características de RouterOS, probar reglas de firewall, experimentar con bridging y aprender conceptos de redes sin hardware de producción.

Pruebas multi-arquitectura

Probar configuraciones de RouterOS en arquitecturas x86_64 y aarch64 usando QEMU con firmware apropiado (SeaBIOS para x86, UEFI para ARM) y opciones de aceleración.

Prueba estos prompts

Configuración básica de CHR 
Ayúdame a configurar RouterOS CHR en QEMU. Necesito descargar la imagen estable más reciente e iniciarla con aceleración KVM y el puerto 9180 para la API REST.
Integración con GitHub Actions CI 
Escribe un workflow de GitHub Actions que descargue RouterOS CHR, lo inicie con KVM si está disponible (con fallback a TCG), espere el arranque y luego ejecute pruebas de API REST.
Configuración de arranque UEFI para ARM64 
Configura QEMU para iniciar RouterOS CHR aarch64 en macOS Apple Silicon. Incluye la configuración de pflash UEFI y la configuración explícita del dispositivo virtio-blk-pci.
Depuración de fallos de arranque 
RouterOS CHR falla al iniciar con una pantalla en blanco. La imagen de disco usa if=virtio en aarch64. ¿Qué podría estar mal y cómo lo soluciono?

Mejores prácticas

  • Usar -device virtio-blk-pci explícito en lugar de atajo if=virtio en aarch64 para evitar la trampa MMIO que causa fallos de arranque silenciosos
  • Verificar la escritura en /dev/kvm (no solo la existencia) antes de habilitar KVM, y siempre hacer fallback a TCG correctamente en caso de que KVM no esté disponible
  • Usar patrones de reenvío de puertos como tcp::9180-:80 en lugar de codificar IPs localhost para hacer la configuración portable y reutilizable

Evitar

  • No usar if=virtio en arquitectura aarch64 - esto se resuelve como MMIO que RouterOS no soporta, causando fallos de arranque silenciosos
  • No omitir la verificación de permisos de KVM - /dev/kvm puede existir pero no ser legible, y QEMU no hace fallback silencioso a TCG en errores de permiso
  • No usar git pull && git push en builds CI concurrentes - usar el patrón retry-with-rebase para evitar rechazos de push por condiciones de carrera

Preguntas frecuentes

¿Cuál es el límite de velocidad en la licencia CHR gratuita?
La licencia CHR gratuita limita el rendimiento de interfaz a 1 Mbps. Las llamadas a la API REST, SSH, WinBox y acceso a WebFig no se ven afectados. Este límite aplica solo al reenvío real de datos entre interfaces.
¿Por qué QEMU Guest Agent no funciona con aceleración HVF?
El daemon QGA de RouterOS solo se inicia cuando detecta un hipervisor KVM vía CPUID. Con HVF (macOS) o TCG (emulación de software), CPUID 0x40000000 no devuelve cadena de vendor KVM, por lo que el daemon nunca se inicia. Usar Linux con KVM para pruebas de QGA.
¿Cómo elijo entre SeaBIOS y UEFI para el arranque de CHR?
Usar SeaBIOS para x86_64 (por defecto, arranque más rápido). Usar UEFI para arquitectura ARM aarch64. En x86_64, solo SeaBIOS puede iniciar la partición de arranque propietaria; OVMF no puede leerla.
¿Por qué mi CHR aarch64 se queda pegado en el arranque con if=virtio?
En máquina virt aarch64, if=virtio se resuelve como transporte MMIO. RouterOS tiene virtio_pci pero no controlador virtio_mmio, por lo que el kernel se detiene silenciosamente. Siempre usar -device virtio-blk-pci explícito en aarch64.
¿Puedo ejecutar múltiples instancias de CHR simultáneamente?
Sí. Usar puertos de host únicos para cada instancia (9180, 9181, 9182 para API REST, etc.). Cada instancia necesita su propia imagen de disco y seguimiento de PID para limpieza.
¿Qué método de aceleración debo usar?
Usar KVM en Linux cuando las arquitecturas de host y guest coincidan. Usar HVF en macOS Apple Silicon para guests aarch64. Usar TCG como fallback en todas las plataformas cuando la aceleración de hardware no esté disponible.

Detalles del desarrollador

Autor

tikoci

Licencia

MIT

Repositorio

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

Ref.

main

Estructura de archivos

📁 references/

📄 chr-licensing.md

📄 github-actions-ci.md

📄 known-issues.md

📄 virtio-drivers.md

📄 SKILL.md