MikroTik Installer

Ein Windows-Programm, mit dem sich MikroTik-Router/-Switches in wenigen, klar geführten Schritten einrichten lassen – auch ohne Netzwerk-Vorkenntnisse. Statt WinBox-Menüs und RouterOS-Fachbegriffen gibt es ein Interview: Verbindung herstellen, ein paar verständliche Fragen beantworten, fertig.

Hinweis: Dies ist ein unabhängiges, privates Open-Source-Projekt ohne jede kommerzielle Absicht. Es steht in keiner Verbindung zu MikroTik und wird nicht von MikroTik unterstützt, gesponsert oder geprüft. Siehe Markenrechte & Haftungsausschluss.

Was der Assistent einrichtet

Schritt für Schritt, mit Erklär-Tooltips (ⓘ) bei jedem Fachbegriff:

1. Verbindung – IP-Adresse, Benutzername, Passwort (optional „Passwort merken"); „Router im Netzwerk suchen" findet MikroTik-Geräte per MNDP auch ohne passende IP (siehe unten); bereits erfolgreich verbundene Geräte erscheinen als „Bekannte Router" in der Sidebar; die Testumgebung bietet simulierte Router ohne eigene Hardware
2. Was möchtest du tun? – Weiche direkt nach dem Verbinden: kompletter Einrichtungs-Assistent (Standard) oder direkt zu „Backup & Wartung" (siehe unten) — Letzteres überspringt den kompletten restlichen Assistenten
3. Geräte-Erkennung – liest Modell, RouterOS-Version, Seriennummer und Schnittstellen (mit Link-Status-Punkt) aus
4. Vorhandene Netzwerke – bei einem Bestandsgerät: nach Kategorien gruppierte, anklickbare Grafik der bereits eingerichteten Bridges, VLANs, IP-Adressen, DHCP-Server, WLANs und IP-gebundenen Firewall-/NAT-Regeln (siehe unten); bei werksneuen Geräten erscheint nur ein kurzer Hinweis
5. Geräte im Netzwerk – nach Anschluss gruppierte Liste aller aktuell erkannten Geräte (aus DHCP-Leases, ARP- und Bridge-Host-Tabelle zusammengeführt), mit der Möglichkeit, einem Gerät direkt eine feste IP-Adresse zuzuweisen oder das wieder rückgängig zu machen (siehe unten)
6. Modus wählen (nur mit „Professioneller Netzwerker" in den Einstellungen) – geführter Assistent (Standard) oder Experten-Modus: Letzterer blendet in den folgenden Schritten zusätzliche, technischere RouterOS-Optionen ein (siehe unten)
7. Internet-Zugang – WAN-Schnittstelle, DHCP oder feste IP, NAT
8. Heimnetzwerk (DHCP) – Bridge, IP-Bereich, DHCP-Server, DNS
9. VLANs (optional) – zusätzliche, getrennte Netzwerke (z. B. Gäste, IoT), im Experten-Modus wahlweise fest einem oder mehreren Anschlüssen zugeordnet (portbasiert, siehe unten)
10. WLAN (übersprungen, wenn nicht vorhanden – oder bewusst abwählbar, z. B. bei einem reinen Switch)
11. Firewall – sichere Basisregeln, optionale Portfreigaben
12. Zusammenfassung – alle geplanten Änderungen im Klartext, automatisches Backup auf dem Gerät vor dem Anwenden, PDF-Export mit allen Zugangsdaten inkl. WLAN-QR-Code zum Ausdrucken/Aufbewahren
13. RouterOS-Update (optional) – prüft auf eine neuere RouterOS-Version und kann sie mit deutlicher Warnung starten

Nichts wird am Gerät verändert, bevor der Nutzer in der Zusammenfassung ausdrücklich auf „Jetzt einrichten“ klickt (Ausnahmen: die ausdrücklichen Aktionen in „Backup & Wartung“ und „Feste IP zuweisen“ im LAN-Scanner, siehe unten).

Router im Netzwerk finden (MNDP)

„Router im Netzwerk suchen" im Verbindungs-Schritt schickt eine MNDP-Anfrage (MikroTik Neighbor Discovery, UDP 5678) ins lokale Netz und sammelt vier Sekunden lang die Antworten — dieselbe Liste, die WinBox unter „Neighbors" zeigt. Gefunden wird über die MAC-Adresse, also auch ein Router mit kaputter oder unpassender IP-Konfiguration. „IP übernehmen" trägt die Adresse ins Formular ein; hat ein Router keine IP, bleibt nur WinBox per MAC (Hinweis + „MAC kopieren").

Testumgebung

Drei simulierte Router (CHR, hAP ac2, CRS326 — alle admin/admin unter 127.127.127.127–.129) lassen sich im Verbindungs-Schritt per Klick verbinden, auch in der veröffentlichten Version. Es findet keinerlei Netzwerkverbindung statt; Änderungen bleiben bis zum Beenden der App erhalten (auch über einen simulierten Neustart hinweg). Abschaltbar unter Einstellungen → „Testumgebung anbieten".

Vorhandene Netzwerke (IST-Zustand-Analyse)

Bei einem bereits konfigurierten Bestandsgerät liest der dritte Schritt automatisch aus, was dort schon eingerichtet ist, und zeichnet es als Diagramm: jeder Knoten ist eine Bridge, ein VLAN, eine IP-Adresse, ein DHCP-Server, ein WLAN, eine IP-gebundene Firewall-/NAT-Regel oder der Internet-Zugang. Die Grafik ist in Kategorie-Spalten von links nach rechts gruppiert (Internet → Netzwerk-Schnittstellen → IP-Adressen → DHCP-Server → Firewall-Regeln) für eine klare Übersicht statt eines einzelnen unübersichtlichen Baums. Ein Klick auf einen Knoten hebt alles hervor, was mit ihm verbunden ist — sowohl den Weg („Hops") bis zum Internet-Zugang als auch alles, was von diesem Knoten abhängt (z. B. zeigt ein Klick auf eine Bridge alle angeschlossenen Ports, VLANs, IP-Adressen und DHCP-Server). Rein informativ — verändert nichts am Gerät und fließt nicht in die vom Assistenten geplante Konfiguration ein. Bei einem werksneuen Gerät ohne bestehende Konfiguration erscheint statt der Grafik nur ein kurzer Hinweis.

Geräte im Netzwerk (LAN-Scanner)

Der LAN-Scanner führt DHCP-Leases (/ip/dhcp-server/lease), die ARP-Tabelle (/ip/arp) und die Bridge-Host-Tabelle (/interface/bridge/host) per MAC-Adresse zu einer Geräteliste zusammen, gruppiert nach dem physischen Anschluss, an dem ein Gerät tatsächlich hängt (aus der Bridge-Host-Tabelle — ARP/Lease zeigen bei gebrückten Setups sonst nur die Bridge selbst, nicht den echten Port). Geräte ohne Hostnamen in der Lease bekommen den Namen, den der Router selbst im DNS eingetragen hat (/ip/dns/static, z. B. nas.lan). Rein informativ bis auf eine Aktion: Bei einem Gerät mit DHCP-Lease lässt sich diese per Klick fest zuweisen (RouterOS „Make Static") oder wieder entfernen. Ein „Aktualisieren"-Button lädt die Liste jederzeit neu.

Werkzeuge je Gerät: Ping, Traceroute und DNS-Auflösung laufen vom Router aus über dieselbe API-Verbindung (kein SSH nötig; die DNS-Auflösung bevorzugt den Eintrag name.domain im Router-DNS). Der Port-Scan läuft direkt von diesem PC aus und prüft 19 gängige TCP-Ports: rot = offen (dort antwortet ein Dienst), grün = geschlossen, grau = keine Antwort (Firewall oder Gerät aus). Adressen und Namen aus DHCP-Leases kann ein Gerät frei wählen — sie werden vor jeder Verwendung gegen eine Zeichen-Allow-List geprüft.

RouterOS kennt keinen direkten „wieder dynamisch machen"-Befehl — das Rückgängig-Machen entfernt den Lease-Eintrag komplett. Das betroffene Gerät merkt das aber nicht sofort: Es hält seine bisherige IP-Adresse client-seitig weiter, bis es von sich aus eine neue DHCP-Anfrage stellt (Lease-Renewal-Timer) oder der Link neu aufgebaut wird (Kabel/WLAN trennen und neu verbinden, Neustart). Bis dahin zeigt die Zeile „Feste IP entfernt" mit deaktiviertem Button und einem erklärenden Hinweistext, statt kommentarlos auszugrauen. Wie die IST-Zustand-Analyse verändert dieser Schritt nichts an der vom Assistenten geplanten Soll-Konfiguration.

Experten-Modus

Wer RouterOS kennt, kann im vierten Schritt den Experten-Modus wählen. Die Schritte 5–9 zeigen dann zusätzlich (Laien-Modus bleibt exakt wie zuvor, Defaults entsprechen dem bisherigen Verhalten):

• Internet-Zugang: DHCP-Standardroute/-DNS an/aus, feste MTU, NAT nur für ein bestimmtes Subnetz
• Heimnetzwerk: DHCP-Lease-Zeit, Domainname, NTP-Server
• VLANs: frei wählbares Adress-Präfix, eigener DNS-Server, Lease-Zeit, „Von Heimnetz isolieren“ (automatische Trennregel), Anschlüsse fest zuordnen (portbasiert, siehe unten)
• WLAN: WPA2/WPA3/gemischt, SSID verstecken, Band/Kanal festlegen
• Firewall: Portfreigabe auf eine Quell-IP beschränken, Portbereiche statt Einzelport, Zugriffe protokollieren, IP-/Subnetz-Sperrliste

Backup & Wartung

Eigenständiger Bereich, erreichbar direkt im zweiten Schritt („Was möchtest du tun?") — ohne den restlichen Einrichtungs-Assistenten zu durchlaufen. Liest das verbundene Gerät selbst aus und zeigt sofort: vorhandene Backups auf dem Gerät (nach Tag gruppiert), einen „Neues Backup erstellen"-Button für eine frische, unabhängige Sicherung (z. B. vor eigenen Änderungen direkt in WinBox — erscheint sofort in der Liste) und „Aktualisieren" zum erneuten Auflisten. Ein Backup lässt sich direkt aus der Liste zurückspielen.

• Verschlüsselung: Ist in den Einstellungen ein Backup-Passwort gesetzt, verschlüsselt RouterOS jedes neue Backup selbst (password=…, encryption=aes-sha256); der Dateiname bekommt die Endung -enc, die Liste zeigt ein Schloss, und beim Zurückspielen wird das Passwort mitgegeben. Ohne Passwort weist der Bereich darauf hin, dass Backups unverschlüsselt entstehen. Das Passwort liegt im Windows-Anmeldeinformationsspeicher.
• Handsicherung zählt: Ein von Hand erstelltes Backup ersetzt 10 Minuten lang die automatische Sicherung vor der nächsten Änderung (Anwenden, Zurückspielen, Werksreset) — kein Backup-Stapel für jeden Handgriff.
• Wartung: „Jetzt neu starten"; bei RouterBOARD-Hardware die installierte und die mitgelieferte Firmware mit „Firmware aktualisieren und neu starten"; als Notfallschalter „Auf Werkseinstellungen zurücksetzen" (nur nach Bestätigung, vorher eigene Sicherung, RouterOS legt zusätzlich selbst eine an; danach ist das Gerät meist unter 192.168.88.1 erreichbar, die Verbindung wird beendet).
• Automatisches Wiederverbinden: Nach Neustart, Firmware-Update, Zurückspielen und RouterOS-Update wartet der Assistent, bis das Gerät wieder antwortet (alle 5 s ein Versuch, Zähler in der Sidebar, Aufgabe nach etwa 5 Minuten) und liest danach alles neu ein. Zusätzlich prüft ein Herzschlag alle 30 s bei aktivem Fenster, ob die Verbindung noch steht, und verbindet bei einem Abbruch selbst neu.

RouterOS prüft beim Zurückspielen selbst nicht, ob ein Backup zum verbundenen Gerät passt — es importiert klaglos eine Fremd-Konfiguration mit ggf. falsch zugeordneten Interfaces. Der Assistent verhindert das mit einer vierstufigen Prüfung: Jedes hier selbst erstellte Backup trägt Gerätemodell, Architektur und Seriennummer im Dateinamen (z. B. mikrotik-installer-RB750Gr3_arm_414403A029A5-20260917-193000.backup, jeweils per _ getrennt).

• Passt genau (Modell, Architektur und Seriennummer stimmen überein, oder die Seriennummer ist auf einer Seite nicht bekannt) — direkt wiederherstellbar.
• Gleiches Modell, anderes physisches Gerät (Modell und Architektur passen, aber eine bekannte, abweichende Seriennummer) — gelb markiert, nur nach ausdrücklicher Bestätigung „auf eigene Gefahr" wiederherstellbar. Erkennt z. B. ein baugleiches Ersatzgerät, das ein reiner Modell-Abgleich fälschlich als identisch durchließe.
• Anderes Modell oder andere Architektur — rot markiert, ohne Override-Möglichkeit blockiert (echtes Risiko falsch zugeordneter Interfaces).
• Nicht prüfbar (kein erkennbarer Name, z. B. ein Backup aus WinBox) — nur nach ausdrücklicher Bestätigung, dass es zum Gerät passt.

Wie beim normalen Anwenden wird vor dem Zurückspielen zusätzlich eine Sicherung des aktuellen Zustands erstellt — falls das Zurückspielen nicht das gewünschte Ergebnis war, lässt sich so auch das noch rückgängig machen. Das Gerät startet nach dem Zurückspielen automatisch neu.

Isolierte Netzwerke

„Von Heimnetz isolieren" im VLAN-Schritt legt nicht nur Drop-Regeln für die Weiterleitung in beide Richtungen an (mit Kommentar Isolation vlan20 -> bridge), sondern sperrt auch die Router-Verwaltung (WebFig, SSH, WinBox, API) aus dem isolierten Netz — nur DNS und DHCP zum Router bleiben erlaubt. Ohne das erreichten Gäste die Anmeldeseite des Routers (in der Mac-Version beim Hotspot-Test gefunden). Bereits bestehende Verbindungen des isolierten Netzes werden gekappt, sonst liefen sie trotz neuer Regel über die vorgelagerte „established"-Regel weiter. Ältere Regeln ohne Kommentar werden weiterhin als vorhanden erkannt und nicht doppelt angelegt.

Einstellungen

Erreichbar unten in der Sidebar: Erscheinungsbild (Wie System / Hell / Dunkel), Update-Prüfung beim Verbinden, „Professioneller Netzwerker" (blendet den Experten-Modus im Assistenten ein, Standard: aus), „Testumgebung anbieten", Ordner für Backups auf diesem PC, Backup-Passwort und „Einführung beim nächsten Start erneut zeigen". Beim ersten Start erscheint eine kurze Einführung mit denselben Grundeinstellungen, bis „Fertig" oder „Überspringen" gedrückt wurde. Die App startet maximiert mit einem kurzen Startbildschirm.

Portbasierte VLANs

Im Experten-Modus lässt sich jedem VLAN im VLAN-Schritt zusätzlich eine Checkliste von Anschlüssen zuordnen (z. B. „Ether4"). Geräte, die dort eingesteckt werden, gehören dann automatisch zu diesem Netzwerk – auch ohne eigene VLAN-Unterstützung (802.1Q-Tagging), z. B. ein einzelner Access Point, eine smarte Steckdose oder eine Netzwerkdose im Gästezimmer. Ohne diese Auswahl bleibt ein VLAN wie bisher rein „getaggt" und ist nur über einen VLAN-fähigen Switch/Access Point erreichbar.

Ein Anschluss kann immer nur einem Netzwerk zugeordnet sein; eine Doppelzuordnung wird erkannt und blockiert „Weiter" mit einer Fehlermeldung. Technisch aktiviert das erst beim Anwenden die Bridge-VLAN-Filterung (vlan-filtering) auf der Heimnetz-Bridge – und zwar bewusst als allerletzten Schritt, nachdem alle PVID- und Bridge-VLAN-Tabellen-Einträge stehen, damit dabei keine Verbindung (auch nicht die eigene, laufende Einrichtung) unterbrochen wird. Die zugeordneten Anschlüsse erhalten zusätzlich frame-types=admit-only-untagged-and-priority-tagged und ingress-filtering=yes, damit ein daran angeschlossenes Gerät sich nicht per manuell getaggten Frames in ein anderes VLAN (z. B. das Heimnetz) einschleichen kann. Anschlüsse ohne eigene VLAN-Zuordnung bleiben unverändert Teil des normalen Heimnetzes.

Eingabevalidierung

Adress-, Bereichs- und Portfelder in WAN, Heimnetzwerk, VLANs und Firewall werden direkt beim Tippen geprüft (IP-/„Adresse/Präfix"-Format, Start ≤ Ende bei Adress- und Portbereichen, Portzahlen 1–65535) und zeigen bei ungültiger Eingabe sofort eine rote, laientaugliche Fehlermeldung statt erst beim Anwenden mit einer RouterOS-Fehlermeldung zu scheitern. „Weiter" bleibt so lange gesperrt, bis alle Felder des aktuellen Schritts gültig sind. Behebt nebenbei einen echten Absturzpfad: Ohne diese Prüfung riefen LanConfigurator/VlanConfigurator bei jedem Tastendruck ungeprüft IPAddress.Parse auf einer möglicherweise unvollständigen Eingabe auf.

Bekannte Router

Nach jeder erfolgreichen Verbindung merkt sich der Assistent Host, Benutzername und (sobald die Geräte-Erkennung gelaufen ist) die Hardware-Bezeichnung als Namensvorschlag — rein lokal, ohne weiteren Geräte-Zugriff. Das Passwort liegt dabei nicht in der lokalen Datei, sondern im Windows-Anmeldeinformationsspeicher (Systemsteuerung → Anmeldeinformationsverwaltung).

Bekannte Router leben ausschließlich als kompakte Kurzauswahl dauerhaft in der Sidebar, unabhängig vom aktuellen Schritt — das Hauptfenster selbst (Verbindungs-Schritt) zeigt nur noch das Formular für ein neues, noch unbekanntes Gerät, ohne Dopplung. Ein Klick auf einen Sidebar-Eintrag verbindet direkt (ohne Umweg über das Formular) und springt bei Erfolg automatisch weiter; ein kleines Papierkorb-Symbol entfernt einen Eintrag wieder. Der Name kommt automatisch vom Gerätemodell — eine eigene Umbenennung gibt es bewusst nicht mehr, um die Sidebar kompakt zu halten. Sobald eine Verbindung besteht, zeigt dieselbe Stelle stattdessen Gerätename/-modell (sobald die Geräte-Erkennung gelaufen ist, bis dahin nur die Adresse) mit einem „Wechseln"-Button, um die Verbindung zu trennen und zu einem anderen Gerät zurückzukehren.

Da viele MikroTik-Geräte werksseitig dieselbe Standardadresse verwenden (192.168.88.1/admin), würde eine reine Host+Benutzername-Zuordnung mehrere unterschiedliche physische Geräte fälschlich als dasselbe behandeln. Der Assistent liest deshalb zusätzlich die Seriennummer aus (/system/routerboard) und legt bei einem Host+Benutzername-Treffer mit unterschiedlicher Seriennummer einen eigenen Eintrag an, statt den bestehenden zu überschreiben — kennt eine Seite (noch) keine Seriennummer (z. B. ein virtuelles CHR-Testgerät), wird im Zweifel derselbe Eintrag aktualisiert.

Für Nutzer

• Windows 10/11, keine Installation nötig
• Einfach MikroTik-Installer.exe herunterladen und starten – eine einzelne, eigenständige Datei (~67 MB), kein separates .NET muss installiert werden
• Portable: läuft von jedem Ordner/USB-Stick, schreibt nichts in die Registry; Einstellungen und „Bekannte Router" liegen unter %AppData%\MikroTik-Installer\ (settings.json, saved-routers.json), Passwörter im Windows-Anmeldeinformationsspeicher

Ist die Datei vertrauenswürdig?

Jede Version wird nicht lokal, sondern öffentlich nachvollziehbar per GitHub Actions direkt aus diesem Quellcode gebaut (siehe .github/workflows/release.yml) – niemand fügt der exe manuell etwas hinzu. Bei jedem Release findest du zusätzlich:

• eine .sha256-Prüfsumme neben der exe, mit der du die Integrität deines Downloads überprüfen kannst (Get-FileHash MikroTik-Installer.exe -Algorithm SHA256 unter PowerShell)
• einen VirusTotal-Scan-Link in den Release-Notizen, der die exakt gebaute Datei durch 70+ Antiviren-Engines prüft

Die exe ist nicht mit einem kostenpflichtigen Code-Signing-Zertifikat signiert – Windows SmartScreen zeigt daher beim ersten Start ggf. „Unbekannter Herausgeber" an. Das ist bei kostenlosen Open-Source-Projekten ohne Firmenhintergrund normal und kein Hinweis auf Schadsoftware; über „Weitere Informationen" → „Trotzdem ausführen" lässt sich der Hinweis bestätigen.

Für Entwickler

Voraussetzungen

• .NET 8 SDK

Bauen & Testen

dotnet build
dotnet test src/MikrotikInstaller.Core.Tests/MikrotikInstaller.Core.Tests.csproj
dotnet run --project src/MikrotikInstaller.App

Release-Build (eine einzelne .exe)

.\build-release.ps1

Erzeugt src/MikrotikInstaller.App/bin/Release/net8.0-windows/win-x64/publish/MikroTik-Installer.exe – self-contained, single-file, ohne .NET-Runtime-Installation beim Nutzer.

Es gibt außerdem einen Gitea-Actions-Workflow (.gitea/workflows/build.yml), der das bei jedem Push automatisch übernimmt.

CI/CD (Gitea Actions)

Ein selbstgehosteter Runner (gitea-runner, Name „danielpc-windows") läuft im User-Modus ohne Docker direkt auf dem Windows-Entwicklungsrechner und nutzt dessen bereits installiertes .NET 8 SDK – daher kein actions/setup-dotnet-Schritt im Workflow (der würde versuchen, nach C:\Program Files\dotnet zu schreiben, wofür dem User-Modus-Runner die Rechte fehlen). runs-on: windows-latest im Workflow muss daher exakt dem Label entsprechen, mit dem der Runner registriert wurde (windows-latest:host).

Läuft der Runner nicht dauerhaft im Hintergrund (z. B. nach einem Neustart), bleiben Pushes einfach in der Warteschlange, bis er wieder gestartet wird – nichts geht verloren, es gibt nur keine sofortige Rückmeldung.

Testumgebung (Demo-Client)

DemoRouterOsClient simuliert drei Router (127.127.127.127–.129, admin/admin) komplett im Arbeitsspeicher, inkl. Backups, Firmware-Update, Ping/Traceroute/DNS. Seit dem Abgleich mit der Mac-Version (v1.8.0) auch in Release-Builds verfügbar (Abschnitt „Testumgebung" im Verbindungs-Schritt, abschaltbar in den Einstellungen) — die Adressen liegen im Loopback-Bereich und können nie ein echter Router sein. Ein Gerät je Adresse für die Laufzeit der App, damit Änderungen ein simuliertes Wiederverbinden überstehen.

Projektstruktur

src/
  MikrotikInstaller.App/          WPF-UI (Views, ViewModels, Wizard-Shell)
  MikrotikInstaller.Core/         RouterOS-Clients, Konfigurationslogik, PDF-Export
  MikrotikInstaller.Core.Tests/   Unit-Tests für Core (xUnit)

Core kapselt die gesamte RouterOS-Kommunikation hinter IRouterOsClient – wahlweise über die REST-API (RouterOS 7+) oder die binäre API (Port 8728/8729, ältere Geräte), mit automatischem Fallback. Jede Konfigurations-Funktion (WAN, LAN, VLAN, WLAN, Firewall) erzeugt sowohl die auszuführenden RouterOS-Befehle als auch eine laienverständliche Klartext-Zusammenfassung.

App ist reines MVVM: Ein generischer Wizard-Shell (MainViewModel) navigiert durch eine Liste von Schritt-ViewModels; Schritte ohne Inhalt für das jeweilige Gerät (z. B. WLAN ohne WLAN-Hardware) werden automatisch übersprungen.

Architektur

flowchart TB
    subgraph App["MikrotikInstaller.App (WPF, MVVM)"]
        MainVM["MainViewModel<br/>Wizard-Navigation"]
        Steps["Step-ViewModels<br/>Connection - DeviceOverview - NetworkAnalysis - ModeSelection -<br/>Wan - Lan - Vlan - Wlan - Firewall - Summary - Update"]
        Session["WizardSession<br/>geteilter Zustand über alle Schritte"]
        MainVM --> Steps --> Session
    end

    subgraph Core["MikrotikInstaller.Core"]
        Configurators["*Configurator<br/>Wan / Lan / Vlan / Wireless / Firewall<br/>erzeugen ConfigurationAction + Klartext-Zusammenfassung"]
        Factory["RouterOsClientFactory<br/>waehlt REST / Binary / Demo"]
        IClient(["IRouterOsClient"])
        Rest["RestRouterOsClient<br/>RouterOS 7+, Port 443/80"]
        Binary["BinaryRouterOsClient<br/>Port 8728/8729"]
        Demo["DemoRouterOsClient<br/>Testumgebung, kein echtes Geraet"]
        Discovery["DeviceDiscoveryService"]
        Backup["RouterBackupService"]
        Updates["RouterOsUpdateService"]
        Export["SummaryPdfExporter + WifiQrCodeGenerator"]

        Factory --> Rest & Binary & Demo
        Rest -.-> IClient
        Binary -.-> IClient
        Demo -.-> IClient
    end

    Device[("MikroTik-Geraet<br/>RouterOS")]

    Session --> Factory
    Steps --> Configurators --> IClient
    Steps --> Discovery & Backup & Updates & Export
    Discovery --> IClient
    Backup --> IClient
    Updates --> IClient
    Rest --> Device
    Binary --> Device

Verbindungsaufbau läuft immer über RouterOsClientFactory: REST-API zuerst, bei Fehlschlag Fallback auf die binäre API; nur bei den Testumgebungs-Adressen 127.127.127.127–.129 wird stattdessen der DemoRouterOsClient verwendet. Zeitlimits gelten je Zugriffsart (RouterOsTimeouts: Lesen 15 s, Schreiben 30 s, Befehle wie Backup/Update 120 s, Verbindungstest 8 s), weil schwache Hardware für Backups deutlich länger braucht. Die binäre API arbeitet Zugriffe strikt nacheinander ab (sie ordnet Antworten nur über die Reihenfolge zu) und liest nach einer Fehlerantwort auch das folgende !done mit. IRouterOsClient.RunAsync liefert die Ausgabe eines Befehls (z. B. /ping), RouterOsException.IsConnectionLost unterscheidet einen Verbindungsabbruch von einer Ablehnung durch das Gerät. Alle Configurators, DeviceDiscoveryService, RouterBackupService und RouterOsUpdateService sprechen ausschließlich gegen die Abstraktion IRouterOsClient, nie gegen eine konkrete Implementierung.

Der ModeSelectionStepViewModel-Schritt setzt lediglich WizardSession.IsExpertMode (bool). Jeder folgende Step-ViewModel liest dieses Flag als Passthrough-Property; die zugehörige View blendet damit zusätzliche Eingabefelder ein oder aus (Visibility-Binding auf denselben BoolToVisibilityConverter, der auch sonst im Wizard verwendet wird). Es gibt keine zweite Steps-Liste und keinen separaten Codepfad — bei nicht gesetzten Experten-Feldern (Default) erzeugen die Configurators exakt dieselben RouterOS-Befehle wie im reinen Laien-Modus.

IST-Zustand-Analyse

flowchart LR
    Service["NetworkAnalysisService<br/>Core/Analysis"]
    Facts["Existing*-Records<br/>Bridge-Ports, VLANs, IP-Adressen,<br/>DHCP-Server, Routen, WLANs, Firewall-Regeln"]
    StepVM["NetworkAnalysisStepViewModel<br/>App"]
    Graph["TopologyNodeViewModel / TopologyConnectionViewModel<br/>Kategorie-Spalten (links -&gt; rechts), IsHighlighted"]
    Editor["nodify:NodifyEditor<br/>Klick -&gt; SelectedItem -&gt; Teilbaum-Hervorhebung"]

    Service --> Facts --> StepVM --> Graph --> Editor

NetworkAnalysisService fragt (fehlertolerant pro Endpunkt) /interface/bridge/port, /interface/vlan, /ip/address, /ip/pool, /ip/dhcp-server, /ip/route, /interface/wireless, /ip/firewall/nat und /ip/firewall/filter ab und liefert reine Fakten — keine Positions-/Grafik-Konzepte, Core bleibt UI-frei. Firewall-/NAT-Regeln werden nur aufgenommen, wenn sie eine konkrete Adresse binden (to-addresses bzw. dst-address/src-address) — generische, nur interface-basierte Basisregeln bleiben bewusst außen vor.

Der Step-ViewModel (App) baut daraus einen Baum: jeder Knoten hat höchstens einen ParentNodeId (Bridge-Port → Bridge, VLAN → Eltern-Interface, IP/DHCP → ihr Interface, Firewall-Regel → die IP-Adresse, deren Subnetz die gebundene Adresse enthält, WAN-Interface → synthetischer „Internet"-Knoten anhand der Standardroute). Positioniert wird in Kategorie-Spalten (TopologyLayout.Bands) von links nach rechts: X = Kategorie-Index, Y = laufende Zeile innerhalb der Spalte (sortiert nach Baum-Tiefe, damit zusammengehörige Knoten wie eine Bridge und ihre Ports nahe beieinander stehen). Kategorie-Beschriftungen sind eigene, nicht anklickbare Einträge im selben Nodify-Item-Raum wie die Knoten, damit sie beim Pan/Zoom exakt mitwandern statt als Overlay zu driften. Ein Klick hebt den kompletten verbundenen Teilbaum hervor (Vorfahren und Nachfahren), nicht nur den Weg nach oben. Die Grafik selbst nutzt Nodify (reines, abhängigkeitsfreies WPF-Steuerelement für MVVM-Node-Editoren) — Klicks laufen über dessen eingebautes SelectedItem-Binding, nicht über eigene Maus-Behandlung.

Datenstruktur

Die wichtigsten Records, die während eines Assistenten-Durchlaufs entstehen und durch WizardSession zusammengehalten werden:

classDiagram
    class WizardSession {
        +IRouterOsClient Client
        +RouterDevice Device
        +bool IsExpertMode
        +string WanInterfaceName
        +string LanBridgeName
        +WanSettings WanSettings
        +LanSettings LanSettings
        +VlanDefinition[] VlanDefinitions
        +WirelessSettings WirelessSettings
        +FirewallSettings FirewallSettings
        +ConfigurationAction[] WanActions
        +ConfigurationAction[] LanActions
        +ConfigurationAction[] VlanActions
        +ConfigurationAction[] WirelessActions
        +ConfigurationAction[] FirewallActions
        +RouterOsUpdateInfo UpdateInfo
    }

    class RouterOsCredentials {
        <<record>>
        +string Host
        +string Username
        +string Password
        +int? RestPort
        +int? BinaryPort
        +bool UseEncryption
        +bool AllowUntrustedCertificate
    }

    class RouterDevice {
        <<record>>
        +string IdentityName
        +string BoardModel
        +string RouterOsVersion
        +string Architecture
        +bool HasWireless
        +InterfaceInfo[] Interfaces
        +string? SerialNumber
    }

    class InterfaceInfo {
        <<record>>
        +string Name
        +InterfaceKind Kind
        +bool IsRunning
        +bool IsDisabled
        +string? Comment
    }

    class InterfaceKind {
        <<enum>>
        Ethernet
        Bridge
        Vlan
        Wireless
        Other
    }

    class WanSettings {
        <<record>>
        +string InterfaceName
        +WanAddressMode Mode
        +string? StaticAddressCidr
        +string? StaticGateway
        +bool UseDhcpDefaultRoute
        +bool UseDhcpDns
        +int? Mtu
        +string? NatSourceAddress
    }

    class LanSettings {
        <<record>>
        +string BridgeName
        +string[] MemberInterfaces
        +string RouterAddressCidr
        +string DhcpPoolStart
        +string DhcpPoolEnd
        +string PrimaryDnsServer
        +string? SecondaryDnsServer
        +string? DhcpLeaseTime
        +string? DomainName
        +string? NtpServer
    }

    class VlanDefinition {
        <<record>>
        +int VlanId
        +string Name
        +string RouterAddressCidr
        +string DhcpPoolStart
        +string DhcpPoolEnd
        +bool IsolateFromLan
        +string? DnsServerOverride
        +string? DhcpLeaseTime
        +string[]? AccessPorts
    }

    class WirelessSettings {
        <<record>>
        +string InterfaceName
        +string Ssid
        +string Password
        +WirelessSecurityMode SecurityMode
        +bool HideSsid
        +string? Band
    }

    class WirelessSecurityMode {
        <<enum>>
        Wpa2
        Wpa3
        Wpa2Wpa3Mixed
    }

    class FirewallSettings {
        <<record>>
        +string WanInterfaceName
        +string LanBridgeName
        +PortForward[] PortForwards
        +string[]? BlockedAddresses
    }

    class PortForward {
        <<record>>
        +string Name
        +string Protocol
        +int ExternalPort
        +string TargetAddress
        +int InternalPort
        +string? AllowedSourceAddress
        +bool LogRule
        +int? ExternalPortRangeEnd
        +int? InternalPortRangeEnd
    }

    class ConfigurationAction {
        <<record>>
        +string Description
        +ApplyAsync(IRouterOsClient, CancellationToken) Task
    }

    class RouterOsUpdateInfo {
        <<record>>
        +bool IsCheckSuccessful
        +string InstalledVersion
        +string? LatestVersion
        +bool IsUpdateAvailable
    }

    class SummaryDocumentData {
        <<record>>
        +string DeviceIdentityName
        +string DeviceModel
        +WanSettings? Wan
        +LanSettings? Lan
        +VlanDefinition[] Vlans
        +WirelessSettings? Wireless
        +FirewallSettings? Firewall
        +string? BackupName
    }

    WizardSession --> RouterDevice
    WizardSession --> WanSettings
    WizardSession --> LanSettings
    WizardSession --> VlanDefinition
    WizardSession --> WirelessSettings
    WizardSession --> FirewallSettings
    WizardSession --> ConfigurationAction
    WizardSession --> RouterOsUpdateInfo
    RouterDevice --> InterfaceInfo
    InterfaceInfo --> InterfaceKind
    WirelessSettings --> WirelessSecurityMode
    FirewallSettings --> PortForward
    SummaryDocumentData --> WanSettings
    SummaryDocumentData --> LanSettings
    SummaryDocumentData --> VlanDefinition
    SummaryDocumentData --> WirelessSettings
    SummaryDocumentData --> FirewallSettings

WanSettings, LanSettings, VlanDefinition[], WirelessSettings und FirewallSettings dienen doppelt: als Eingabe für die *Configurator-Klassen (die daraus ConfigurationActions bauen) und – gebündelt in SummaryDocumentData – als Grundlage für den PDF-Export.

Verwendete Bibliotheken

• WPF-UI – modernes Fluent-Design für WPF
• CommunityToolkit.Mvvm – MVVM-Grundgerüst
• Nodify – anklickbare Netzwerk-Grafik im Schritt „Vorhandene Netzwerke"
• PDFsharp – PDF-Erzeugung
• QRCoder – WLAN-QR-Code

Die MikroTik-Markenfarbe (#009245) wurde aus der offiziellen Website übernommen; das App-Icon ist ein eigenes, neutrales Netzwerk-Symbol (kein MikroTik-Logo).

Roadmap

Die Weiterentwicklung wird als Milestones mit zugehörigen Issues im internen Gitea-Dev-Repository getrackt (nicht auf GitHub, siehe Für Entwickler zur Remote-Aufteilung).

Neun der Milestones (M-*-Präfix) entstanden aus einem Feature-Vergleich mit einer parallel entwickelten, funktional deutlich weiter fortgeschrittenen macOS/SwiftUI-Version desselben Assistenten (unabhängiges privates Repository, unabhängige Implementierung, keine gemeinsame Codebasis) und sollen schrittweise Funktionsparität herstellen.

Milestone	Status	Fokus
v1.0 – Realgerät-Validierung	Offen	Kompletter Wizard-Durchlauf inkl. „Jetzt einrichten" (RouterOS-Befehle, Backup, PDF-Export, Update-Prüfung) gegen ein echtes physisches Gerät verifizieren – größter offener Validierungs-Gap. Dabei insbesondere die portbasierte VLAN-Zuordnung (vlan-filtering) gegen ein Echtgerät prüfen, da bisher nur gegen den simulierten Demo-Client getestet
v1.1 – Release-Housekeeping	Offen	v1.0.0-Tag-Strategie klären, Copyright-Name in LICENSE bestätigen, Trennung Gitea (laufendes Dev) / GitHub (nur Releases) wiederherstellen
v1.2 – Eingabevalidierung	✅ Abgeschlossen	Live-Fehlermeldungen bei ungültigen Eingaben (IP-/Subnetz-Format, Adressbereiche, Portbereiche) direkt in WAN/LAN/VLAN/Firewall, vom Nutzer bestätigt. Dabei nebenbei einen eigenständigen Bug behoben: Firewall-/NAT-Regeln duplizierten sich bei wiederholtem Wizard-Lauf gegen dasselbe Gerät (Issue #19)
v1.3 – SFTP-Backup-Download	Offen	Backup-Download aufs PC per SFTP nachrüsten (bisher liegt das Backup nur auf dem Gerät selbst)
IST-Zustand-Analyse	✅ Abgeschlossen	Kernfunktion umgesetzt und vom Nutzer bestätigt (Kategorie-Grafik, Firewall-/NAT-Regeln, Teilbaum-Hervorhebung). Offen: optisches Feintuning sowie Route-zu-Interface-Zuordnung gegen ein echtes Bestandsgerät verifizieren (derzeit best-effort, RouterOS-versionsabhängig)
CI/CD – Gitea-Actions-Runner	✅ Abgeschlossen	Selbstgehosteter Runner registriert, build.yml erfolgreich scharf getestet (Run #26: Tests + Publish + Artefakt-Upload grün). Läuft aktuell nur, solange der Runner-Prozess manuell gestartet ist — kein Autostart/Dienst eingerichtet
M-Bekannte-Router – Gespeicherte Verbindungen	✅ Abgeschlossen	Zuletzt genutzte Router mit Name/Standort merken, vom Nutzer bestätigt (siehe „Bekannte Router" oben)
M-Geräte – LAN-Scanner	✅ Abgeschlossen	DHCP-Leases + ARP + Bridge-Hosts je Anschluss zusammengeführt, feste IP-Zuweisung (siehe „Geräte im Netzwerk" oben). Offen: Verhalten von „Make Static" gegen ein echtes Gerät verifizieren (Issue #30)
M-Backup-Wartung – Wiederherstellung, Werksreset, Firmware-Update	✅ Abgeschlossen	Backup zurückspielen mit vierstufigem Seriennummer-/Architektur-/Modell-Abgleich, eigenständiger Bereich „Backup & Wartung", Neustart, RouterBOARD-Firmware, Werksreset-Notfallschalter, automatisches Wiederverbinden (siehe oben). Offen nur noch die Echtgerät-Prüfung von /system/backup/load inkl. Passwort (Issue #32)
M-Übersicht-Edit – Direktes Bearbeiten im Diagramm	Offen	IST-Zustand-Diagramm von rein lesend auf bearbeitbar (Rückschreiben ans Gerät) erweitern
M-SSH – SSH-Fallback-Transport	Umgewidmet	Die binäre API deckt ältere Geräte bereits ab; SSH (SSH.NET) wird nur noch für den SFTP-Backup-Download (v1.3) inkl. Hostkey-TOFU gebraucht
M-Netzwerk-Tools – Ping/Traceroute/DNS/Port-Scan	✅ Abgeschlossen	Ping/Traceroute/DNS vom Router über die bestehende API, Port-Scan von diesem PC (siehe LAN-Scanner oben)
M-Live-Traffic – Live-Durchsatzanzeige	Verworfen (vorgeschlagen)	Die Mac-Version hat die Live-Traffic-Anzeige wegen Router-Last wieder entfernt; Issue #26 zur Schließung vorgeschlagen
M-Mac-Abgleich-v1.11	In Arbeit	Nachziehen der Mac-Version v1.11.4 ohne App-Store-Themen, Arbeitspakete P1–P41 in docs/mac-paritaet-plan.md (Issues #37–#69)
M-Experte – Generischer RouterOS-Zugriff	Offen	Eigener Bereich mit generischer Menü-Engine + kuratierten Formularen für die wichtigsten RouterOS-Bereiche, über die bisherigen Experten-Zusatzfelder hinaus
M-i18n – Zweisprachigkeit DE/EN	Offen	Umschaltbare Sprache für die gesamte App

Ablaufplan (Priorisierung)

Reihenfolge oben in der Tabelle bereits danach sortiert; Begründung nach Phasen:

1. Fundament/Sicherheit zuerst ✅ — v1.2 (behebt einen echten Absturzpfad) zusammen mit dem eigenständig gefundenen Firewall-/NAT-Idempotenz-Bug (Issue #19, kein Milestone) und CI/CD sind abgeschlossen. v1.0 (Realgerät-Validierung) bleibt offen, bis Testhardware verfügbar ist — bevor auf der bestehenden Basis neue Flächen entstehen, muss sie gegen echte Hardware stehen.
2. Unabhängige Mac-Paritätsfeatures ohne SSH-Abhängigkeit — M-Bekannte-Router ✅ und M-Geräte/LAN-Scanner ✅ abgeschlossen, M-Backup-Wartung teilweise (Backup-Wiederherstellung ✅, Werksreset/Firmware-Update offen). Noch offen: Rest von M-Backup-Wartung, v1.3 (SFTP-Backup-Download, gleicher Themenbereich, sinnvoll im selben Zug), M-Übersicht-Edit (baut auf der bereits verifizierten Nodify-Integration auf).
3. Transport-Fundament — M-SSH: einzige Mac-Funktion, die einen komplett neuen Transport-Layer braucht (Ping/Traceroute/DNS-Auflösung und /interface monitor-traffic sind reine CLI-Befehle ohne REST-Äquivalent). Bewusst erst nach Phase 2, damit die risikoarmen Features nicht auf die größere Transport-Arbeit warten müssen.
4. Darauf aufbauend — M-Netzwerk-Tools (Port-Scan-Teil ist unabhängig und könnte vorgezogen werden, Ping/Traceroute/DNS brauchen M-SSH) und M-Live-Traffic (falls kein REST-Äquivalent für /interface monitor-traffic existiert, ebenfalls M-SSH-abhängig — das wird als Erstes bei der Umsetzung geprüft).
5. Größtes Einzelstück zuletzt unter den Mac-Milestones — M-Experte (generischer Zugriff auf >300 RouterOS-Menüs) ist der mit Abstand größte Umfang und blockiert nichts anderes; am besten inkrementell über einen längeren Zeitraum, Bereich für Bereich wie beim Mac-Vorbild.
6. Querschnitt zuletzt — M-i18n erst, wenn die UI-Fläche der vorherigen Phasen weitgehend steht, sonst laufend neue unübersetzte Strings.
7. Release-Abschluss — v1.1 (Release-Housekeeping) kurz vor dem tatsächlichen v1.0.0-Tag, nicht vorher.

Abgleich mit Mac v1.11.4 (2026-10-16): Der vollständige Plan mit allen Arbeitspaketen steht in docs/mac-paritaet-plan.md; umgesetzt sind bisher Isolation/Verbindungs-Robustheit, Backup & Wartung, Einstellungen/Einführung/Testumgebung, MNDP-Router-Suche und die Netzwerk-Werkzeuge.

Abgleichs-Rhythmus mit der Mac-Version: Kein einmaliger Abgleich, sondern wiederkehrend — nach Abschluss eines M-*-Milestones hier oder einer entsprechenden Funktion auf Mac-Seite jeweils kurz prüfen, ob sich die READMEs/Milestones beider Projekte noch decken. RouterOS-API-Eigenheiten, die keine sprach-/framework-spezifische Ursache haben (wie der Firewall-Idempotenz-Bug, Issue #19), werden in beide Projekte übernommen, sobald sie auf einer Seite auffallen.

Lizenz

Dieses Projekt steht unter der MIT-Lizenz. Der Quellcode darf frei verwendet, verändert und weiterverbreitet werden – auch in eigenen (auch kommerziellen) Projekten –, solange der Lizenz- und Copyright-Hinweis erhalten bleibt. Die Software wird ohne jede Gewährleistung bereitgestellt („as is").

Markenrechte & Haftungsausschluss

• Kein offizielles MikroTik-Produkt. Dieses Projekt ist eine unabhängige, private Entwicklung und steht in keiner Verbindung zu MikroTikls SIA. Es wird nicht von MikroTik entwickelt, geprüft, unterstützt, gesponsert oder in irgendeiner Form autorisiert.
• Markenrechte bleiben unangetastet. „MikroTik", „RouterOS", „WinBox" und alle weiteren genannten Produkt- und Markennamen sind Marken bzw. eingetragene Marken von MikroTikls SIA. Sie werden hier ausschließlich zur sachlichen Beschreibung der Kompatibilität verwendet (nominativer Gebrauch), nicht um eine Verbindung, Zusammenarbeit oder Billigung durch MikroTik zu suggerieren. Das App-Icon ist ein eigens erstelltes, neutrales Symbol – kein MikroTik-Logo.
• Nicht-kommerzielles Hobbyprojekt. Der Autor verfolgt mit diesem Projekt keinerlei finanzielle Absicht. Es wird kostenlos und ohne Gewinnerzielungsabsicht als Open Source zur Verfügung gestellt, in der Hoffnung, dass es anderen Nutzern beim Einrichten ihrer Geräte hilft.
• Nutzung auf eigene Verantwortung. Wer den Installer einsetzt, ändert Konfigurationen auf eigenen Netzwerkgeräten in eigener Verantwortung. Es wird keine Haftung für Schäden, Datenverlust oder Fehlkonfigurationen übernommen, die durch die Nutzung dieser Software entstehen (siehe auch Gewährleistungsausschluss in der LICENSE).

Sollte MikroTikls SIA Einwände gegen Inhalte dieses Repositories haben, bitte über die Kontaktmöglichkeiten dieses GitHub-Profils melden – entsprechende Inhalte werden umgehend angepasst oder entfernt.