Im Experten-Modus lässt sich jedes VLAN wahlweise fest einem oder
mehreren Anschlüssen zuordnen, statt nur über einen VLAN-fähigen
Switch/Access Point (getaggt) erreichbar zu sein. Aktiviert dafür
Bridge-VLAN-Filterung erst als letzten Schritt (nachdem alle PVID-
und Bridge-VLAN-Tabellen-Einträge stehen), um keine Verbindung
während der Einrichtung zu kappen, und schützt die zugeordneten
Anschlüsse per frame-types/ingress-filtering vor VLAN-Hopping.
Ein Anschluss kann nur einem Netzwerk zugeordnet sein; Konflikte
blockieren "Weiter" mit einer Fehlermeldung statt die Auswahl
stillschweigend zu ändern.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Kategorien (Internet / Netzwerk-Schnittstellen / IP-Adressen / DHCP-Server
/ Firewall-Regeln) sind jetzt Spalten von links nach rechts statt Baendern
untereinander - auf Nutzer-Feedback nach dem Live-Test. Jede Spalte
stapelt ihre Knoten vertikal, sortiert nach Baum-Tiefe/Eltern-Knoten,
damit zusammengehoerige Knoten (z.B. eine Bridge und ihre Ports) nahe
beieinander stehen.
Per headless-Harness verifiziert: fuenf saubere Spalten (X=0/280/560/
840/1120), keine Ueberlappungen. Regulaerer Build/Test/Smoke-Test gruen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ursache gefunden per headless-Reproduktion (WPF-Layout ausserhalb des
sichtbaren Fensters angestossen, da keine Klick-Automatisierung fuer
native Fenster verfuegbar ist): TopologyBandHeaderViewModel.Location war
eine rein schreibgeschuetzte Property. Nodifys ItemContainer.Location ist
aber standardmaessig TwoWay gebunden (damit Drag&Drop den Knoten
zurueckschreiben kann) - beim ersten Layout-Durchlauf warf das eine
InvalidOperationException auf dem UI-Thread, die mangels
DispatcherUnhandledException-Handler den Prozess sofort und ohne jede
Meldung beendete.
Fix: Location bekommt einen (ungenutzten) Setter. Zusaetzlich als
Sicherheitsnetz einen globalen DispatcherUnhandledException-Handler
ergaenzt, der kuenftige unerwartete Fehler als Meldung anzeigt statt den
Prozess stumm zu beenden.
Verifiziert per Konsolen-Harness (WPF-Layout ohne sichtbares Fenster):
View-Konstruktion, Layout-Durchlauf und simulierter Knoten-Klick laufen
jetzt fehlerfrei durch. Ausserdem regulaerer Build/Test/Smoke-Test grün.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Auf Nutzer-Feedback aus dem Live-Test:
- Klick auf einen zentralen Knoten (z.B. WAN oder eine Bridge) hob bisher
nur den Weg nach oben zum Internet-Knoten hervor. Jetzt wird der
komplette verbundene Teilbaum hervorgehoben (Vorfahren UND Nachfahren) -
ein Klick auf eine Bridge zeigt jetzt wirklich alle angeschlossenen
Geraete/Netzwerke.
- Layout war zu eng, Kasten-Inhalte abgeschnitten: Knoten verbreitert
(180->220px), mehr Zeilen-/Spaltenabstand, Label-Text umbricht jetzt
statt mit "..." abgeschnitten zu werden.
- Grafik nach Kategorien gruppiert (Internet / Netzwerk-Schnittstellen /
IP-Adressen / DHCP-Server / Firewall-Regeln) mit Beschriftung je Band,
statt eines reinen Tiefen-Layouts. Kategorie-Label sind eigene, nicht
anklickbare Eintraege im selben Nodify-Item-Raum wie die Knoten, damit
sie beim Pan/Zoom exakt mitwandern statt als Overlay zu driften.
- Neu: Firewall-/NAT-Regeln, die an eine konkrete IP gebunden sind
(Portfreigaben ueber /ip/firewall/nat, Filter-Regeln mit dst-/
src-address), werden als eigene Knoten unter der IP-Adresse eingehaengt,
deren Subnetz die gebundene Adresse enthaelt. Allgemeine, nicht
adressgebundene Basisregeln (z.B. "drop new from WAN") bleiben bewusst
aussen vor, sonst waere die Grafik von Standard-Boilerplate ueberflutet.
2 neue Core-Tests fuer die Firewall-Zuordnung (56 insgesamt, alle gruen).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neuer Wizard-Schritt "Vorhandene Netzwerke" direkt nach der Geräte-
Erkennung. Liest per NetworkAnalysisService (Core) aus, welche Bridges,
VLANs, IP-Adressen, DHCP-Server, Routen und WLANs auf dem Gerät bereits
existieren, und stellt sie als anklickbare Grafik dar (Nodify). Klick auf
einen Knoten hebt die Eltern-Kette bis zum synthetischen "Internet"-Knoten
hervor (Hops/Pfad). Rein informativ, verändert nichts am Gerät und fließt
nicht in die vom Assistenten geplante Soll-Konfiguration ein.
Core liefert reine Fakten (Records in Analysis/), die App-Schicht baut
daraus Knoten/Kanten mit deterministischem Spalten-Layout. Jeder RouterOS-
Endpunkt ist einzeln fehlertolerant (fehlendes Paket, z.B. kein WLAN,
bricht die Analyse nicht ab). Route-zu-Interface-Zuordnung ist best-effort
(gateway-status-Format ist RouterOS-versionsabhängig) — als bekannte
Einschränkung dokumentiert.
Ursprünglich geplant war, den Schritt bei werksneuen Geräten per
ShouldSkip automatisch zu überspringen. Das erwies sich als architektonisch
nicht möglich: die Wizard-Navigation prüft ShouldSkip, bevor
OnActivatedAsync für den Zielschritt läuft, das Analyse-Ergebnis steht zu
dem Zeitpunkt also noch nicht fest. Stattdessen zeigt der Schritt bei
leerem Ergebnis einen kurzen Hinweistext statt einer leeren Grafik.
Demo-Client um Beispieldaten erweitert, damit sich der Schritt über den
Testzugang (127.127.127.127) durchklicken lässt. 9 neue Core-Tests für
NetworkAnalysisService (54 insgesamt, alle grün).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neuer Wizard-Schritt "Modus wählen" nach der Geräte-Erkennung, mit dem
zwischen dem geführten Assistenten und einem Experten-Modus gewählt werden
kann. Im Experten-Modus zeigen die bestehenden Schritte zusätzliche,
technischere Felder (DHCP-Feinsteuerung, MTU, WPA3, Portbereiche,
IP-Sperrlisten, VLAN-Isolation u.a.), die im Laien-Modus verborgen bleiben.
Alle neuen Settings-Felder sind optional mit Defaults, die das bisherige
Verhalten unverändert lassen (45 Tests grün, 7 davon neu für die
Experten-Felder).
Zusätzlich zwei beim Live-Testen gefundene Bugs behoben: der letzte Schritt
zeigte einen dauerhaft ausgegrauten "Weiter"-Button statt eines
"Beenden"-Buttons, und die Texte im neuen Moduswahl-Schritt wurden
abgeschnitten (horizontales StackPanel gab TextBlocks unbegrenzte Breite
zum Messen, dadurch griff TextWrapping nicht — behoben durch Grid mit
fester Spaltenbreite).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SummaryPdfExporter.Export ist [SupportedOSPlatform("windows")], aber das
Test-Projekt zielte auf net8.0 (ohne OS-Angabe). Der Plattform-Analyzer
kannte den Windows-Kontext dadurch nicht und meldete an jeder Aufrufstelle
in SummaryPdfExporterTests.cs eine CA1416-Warnung - so in den Annotationen
des ersten GitHub-Actions-Laufs aufgefallen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Eigenes, neutrales Netzwerk-Symbol (Mittelknoten mit vier Satelliten,
MikroTik-Grün) als app.ico — programmatisch erzeugt, bewusst kein
MikroTik-Logo, um keine Markenrechte zu verletzen. Als Resource statt
Content eingebunden, damit es beim Single-File-Publish mit in der exe
landet statt als separate Datei danebenzuliegen. Eingebunden als:
- ApplicationIcon (Datei-Icon in Explorer/Taskleiste/Alt-Tab)
- Window.Icon
- WPF-UI-TitleBar-Icon (Titelleiste)
- Sidebar-Branding (ersetzt den bisherigen grünen Punkt)
README.md für Gitea: was der Assistent einrichtet, Screenshot,
Hinweise für Nutzer (portabel, keine Installation) und Entwickler
(Bauen/Testen, Release-Build, interner Testzugang, Projektstruktur,
verwendete Bibliotheken).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SatelliteResourceLanguages=de;en beschränkt die mitgelieferten
Sprachpakete der .NET-Laufzeit und Abhängigkeiten (übersetzte
Systemmeldungen, nicht unsere eigenen UI-Texte — die App hat ohnehin
nur deutsche Texte) auf Deutsch/Englisch. Vorher wurden ~20 weitere
Sprachordner (ja, ru, zh-Hans, ...) ungenutzt mitgeschleppt.
Ungepackt: 170 MB -> 155 MB. Komprimierte Single-File-exe: 71,7 MB ->
67 MB. Reines Build-Einstellungs-Flag ohne Code- oder Trimming-Risiko
(im Gegensatz zu PublishTrimmed, das bei WPF-Apps wegen der starken
Reflection-Nutzung unzuverlässig sein kann und deshalb bewusst nicht
aktiviert wurde).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
MikrotikInstaller.App.csproj bekommt Produkt-Metadaten (Name, Version,
Beschreibung) und Publish-Vorgaben, die greifen, sobald ein
RuntimeIdentifier angegeben wird: self-contained (keine separate
.NET-Installation beim Nutzer nötig), eine einzelne komprimierte .exe
statt eines Ordners voller DLLs, Debug-Symbole eingebettet statt als
separate .pdb-Datei daneben (MikrotikInstaller.Core.csproj ebenso).
Ausgabename umbenannt auf "MikroTik-Installer.exe".
Build/Test:
dotnet publish src/MikrotikInstaller.App/MikrotikInstaller.App.csproj -c Release -r win-x64
Ergebnis: eine einzelne ~72-MB-exe unter
src/MikrotikInstaller.App/bin/Release/net8.0-windows/win-x64/publish/
— läuft eigenständig ohne Installation, verifiziert per UI-Automation
(App startet, komplette Sidebar/Navigation funktioniert). Der
Debug-Simulator-Zugang (127.127.127.127/admin/admin) ist im
Release-Build wie vorgesehen nicht erreichbar (#if DEBUG greift).
Ein fertiger Installer (Inno Setup) bleibt bewusst eine spätere
Ausbaustufe — die portable Einzeldatei ist der MVP-Verteilweg.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ShouldSkip übersprang den WLAN-Schritt bisher nur bei Geräten ganz
ohne WLAN-Hardware. Ein Gerät mit vorhandener, aber deaktivierter
WLAN-Schnittstelle (z. B. weil es hier rein als Switch dient) hat
zu Recht "WLAN-fähig" gemeldet — der Schritt blieb aber Pflicht und
verlangte SSID/Passwort, obwohl der Nutzer gar kein WLAN einrichten
wollte.
Neue Checkbox "Kein WLAN einrichten" macht den Schritt explizit
überspringbar: aktiviert, wird "Weiter" ohne SSID/Passwort freigegeben,
die übrigen Felder werden deaktiviert, und es werden keine
WLAN-Änderungen in die Zusammenfassung/Anwendung übernommen.
Neuer InverseBooleanConverter für die IsEnabled-Bindung (die bisherige
Idee, den Visibility-Konverter dafür zu missbrauchen, wäre ein
Typfehler gewesen — Visibility lässt sich nicht in bool/double
konvertieren).
Per UI-Automation verifiziert: Checkbox aktiviert, Felder werden
deaktiviert, "Weiter" wird ohne Eingaben aktiv.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
RouterOsUpdateService nutzt RouterOS' eigene Update-Funktion
(/system/package/update/check-for-updates + /print), inklusive Polling
bis der Status nicht mehr "Checking..." ist. Schlägt die Prüfung fehl
(z. B. weil das Gerät noch keinen Internetzugang hat), wird das als
"nicht geprüft werden konnte" behandelt statt als Fehler.
Zeitlicher Ablauf wie gewünscht: Die Prüfung wird zuerst im Hintergrund
in der Geräte-Erkennung versucht (Schritt 2) — funktioniert nur, wenn
das Gerät zu diesem Zeitpunkt schon Internetzugang hat. Nach
erfolgreichem Anwenden (Schritt 8, wenn WAN eingerichtet wurde) wird
sie automatisch wiederholt. Beide Läufe blockieren die Navigation
nicht (Fire-and-forget im Hintergrund).
Neuer Schritt 9 "RouterOS-Update" zeigt das Ergebnis: nicht geprüft
werden konnte (mit "Erneut prüfen"), bereits aktuell, oder eine neuere
Version verfügbar — dann mit deutlicher Warnung vor dem automatischen
Neustart und einer Pflicht-Checkbox, bevor "Jetzt aktualisieren"
aktiv wird. Komplett optional, keine Pflicht zum Abschluss des
Assistenten.
Zusammenfassungs-Schritt lässt "Weiter" jetzt erst nach erfolgreichem
Anwenden zu (vorher automatisch gesperrt, weil er der letzte Schritt
war — das ist er jetzt nicht mehr).
Simulator-Zugang liefert jetzt eine simulierte verfügbare Version
(7.15.2 → 7.16.1), damit sich auch dieser Schritt gefahrlos
durchspielen lässt.
Per UI-Automation den kompletten Assistenten durchgeklickt: "nicht
geprüft werden konnte"-Zustand (echtes Simulator-Verhalten ohne
Update-Endpunkte) und "Update verfügbar"-Zustand beide verifiziert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ToolTip-Inhalte hängen nicht im normalen visuellen Baum der Seite,
sondern werden erst beim Anzeigen separat verbunden — eine direkte
ElementName-Bindung im ToolTip-Inhalt (wie zuvor verwendet) läuft
daher ins Leere und bleibt leer, ohne einen Fehler zu werfen.
Fix nach dem dafür vorgesehenen WPF-Muster: Der Text wird als Tag auf
das sichtbare SymbolIcon gebunden (das steht im normalen Baum, dort
funktioniert ElementName), der ToolTip-Inhalt liest ihn anschließend
über PlacementTarget.Tag zurück.
Per UI-Automation mit echter, schrittweiser Mausbewegung verifiziert:
Tooltip zeigt jetzt den vollständigen, umbrochenen Erklärtext an.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neues wiederverwendbares Steuerelement InfoHint: ein kleines
"?"-Symbol, das per Hover eine kurze, einfache Erklärung zeigt —
ohne die Formulare optisch zu überladen (nur bei tatsächlich
erklärungsbedürftigen Begriffen, nicht bei Selbstverständlichem wie
"Benutzername" oder "Passwort").
Fachbegriffe jetzt erklärt in allen Schritten:
- Verbindung: IP-Adresse/Hostname, verschlüsselte Verbindung
- Geräte-Erkennung: RouterOS, Architektur, Netzwerkschnittstellen
- Internet-Zugang: Schnittstelle, DHCP, Präfix, Gateway
- Heimnetzwerk: Bridge/interner Name, Router-Adresse, Präfix,
Adressbereich, DNS-Server
- VLANs: VLAN-ID, Router-Adresse
- WLAN: Schnittstelle, SSID
- Firewall: Portfreigabe, Protokoll, Port von außen/am Gerät
Per UI-Automation den kompletten Assistenten erneut durchgeklickt:
alle Schritte rendern weiterhin korrekt, Info-Symbole erscheinen an
den richtigen Stellen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SummaryPdfExporter (PdfSharp, MIT-lizenziert) druckt die Einrichtung
als einseitiges PDF: Internet-Zugang, Heimnetzwerk, VLANs und Firewall
mit den konkreten technischen Daten (IP-Bereiche, Anschlüsse, DNS) in
der linken Spalte, WLAN-Name und -Passwort groß hervorgehoben in der
rechten Spalte — zum Aufbewahren/Ausdrucken, nicht zum vereinfachten
Vorlesen wie die Bildschirm-Zusammenfassung.
Nice-to-have umgesetzt: WifiQrCodeGenerator (QRCoder, MIT-lizenziert)
erzeugt einen QR-Code im Standard-WIFI:-Format, den Handys direkt als
"WLAN beitreten" erkennen. QR-Erzeugung schlägt niemals das gesamte
PDF fehl — bei Problemen (z. B. Sonderzeichen) wird sie einfach
ausgelassen.
Zwei PdfSharp-6-Besonderheiten gelöst:
- Schriftauflösung: PDFsharp 6 löst Schriften nicht mehr automatisch
über GDI auf. WindowsSegoeUiFontResolver liest Segoe UI direkt aus
dem Windows-Schriftartenordner (keine Schriftdatei wird mitgeliefert
— Microsoft-Lizenz).
- Von QRCoder erzeugte PNGs wurden von PDFsharps PNG-Decoder abgelehnt;
über GDI+ (ohnehin transitive Abhängigkeit von QRCoder) nach BMP
normalisiert, das zuverlässig gelesen wird.
Neuer "Als PDF speichern"-Button im Zusammenfassungs-Schritt (vor und
nach dem Anwenden verfügbar) öffnet einen Speichern-Dialog und zeigt
Erfolg/Fehler direkt im Assistenten an.
Per UI-Automation und Sichtprüfung des erzeugten PDFs verifiziert:
korrektes einseitiges Layout, lesbarer QR-Code, alle Daten vorhanden.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Die Zusammenfassung zeigte bisher jede einzelne RouterOS-Aktion als
flache Liste (z. B. "IP-Adressbereich 192.168.88.10-192.168.88.254
für Geräte in deinem Netzwerk reservieren", "DHCP-Server auf
„bridge-lan" aktivieren, ...) — für Laien kaum verständlich und rein
technisch sortiert.
Jeder Configurator (Wan/Lan/Vlan/Wireless/Firewall) bekommt jetzt
zusätzlich BuildFriendlySummary(...): 1-2 kurze, verständliche Sätze
ohne RouterOS-Fachbegriffe, getrennt von den technischen
ConfigurationAction-Beschreibungen (die weiterhin als Fortschrittstext
beim tatsächlichen Anwenden dienen).
WizardSession hält jetzt zusätzlich die rohen Einstellungsobjekte
jedes Schritts (WanSettings, LanSettings, VlanDefinitions,
WirelessSettings, FirewallSettings), damit der Zusammenfassungs-Schritt
daraus bauen kann, was tatsächlich passiert ist — nicht wie.
Die Zusammenfassung zeigt jetzt pro Themenbereich eine eigene Karte
(Internet-Zugang, Heimnetzwerk, optional VLANs, optional WLAN,
Firewall) mit Symbol, Titel und kurzen Stichpunkten; leere Bereiche
(z. B. keine VLANs eingerichtet) werden gar nicht erst angezeigt.
Unit-Tests prüfen u. a., dass die Klartext-Sätze keine RouterOS-Begriffe
wie "NAT" enthalten und dass das WLAN-Passwort nicht in der Anzeige
landet.
Per UI-Automation verifiziert: vier klar getrennte, grün akzentuierte
Karten mit verständlichen Stichpunkten statt einer technischen Liste.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Behebt beide gemeldeten UI-Bugs:
- "Verbindung testen"-Button unsichtbar: Die App war fest auf das
Hell-Theme verdrahtet, während das native Mica-Fenstermaterial dem
Windows-Systemthema folgte — bei aktiviertem Dark Mode entstand ein
Kontrast-Mismatch. App.xaml.cs wendet jetzt beim Start
ApplicationThemeManager.ApplySystemTheme() an, MainWindow.xaml.cs
registriert SystemThemeWatcher.Watch() für Live-Wechsel zur Laufzeit.
- Unterste Elemente in Schritt 2 abgeschnitten: Es fehlte ein
Scroll-Container. Der Inhaltsbereich in MainWindow.xaml ist jetzt
einmal zentral in einen ScrollViewer gefasst (redundante,
uneinheitliche ScrollViewer in einzelnen Schritt-Views entfernt),
sodass bei jeder Fenstergröße gescrollt statt abgeschnitten wird —
"Zurück"/"Weiter" bleiben dabei immer sichtbar und erreichbar.
Farbschema: MikroTik-Markenfarben direkt aus mikrotik.com (CSS)
übernommen — Grün #009245 als Akzent über
ApplicationAccentColorManager (ersetzt die Windows-Systemakzentfarbe
für alle "Primary"-Elemente automatisch), dazu feste Marken-Brushes
für Erfolgs-/Fehlertexte statt hartkodierter Farbnamen.
Neues Shell-Layout: Sidebar mit Marke + Schritt-Übersicht (Nummer,
Titel, grüner Haken für abgeschlossene Schritte, hervorgehobener
aktueller Schritt) ersetzt den bisherigen reinen Fortschrittsbalken —
modernerer, klarerer Assistenten-Look.
Verifiziert per UI-Automation (Screenshots bei normaler und
Mindest-Fenstergröße): Kontrast in Dunkel-Theme korrekt, Navigation
bei wenig Platz scrollt statt abzuschneiden.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Regressionstest zur Diagnose des Weiter-Button-Problems: bestätigt,
dass RouterOsClientFactory.ConnectAsync mit den Simulator-Zugangsdaten
(127.127.127.127/admin/admin) sofort einen DemoRouterOsClient liefert,
ohne jeden Verbindungsversuch übers Netz. Die Kernlogik war korrekt —
Ursache des gemeldeten Problems war die PasswordBox-Bindung (siehe
vorheriger Commit) und ein noch laufender, alter App-Prozess beim Test.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Wpf.Ui.Controls.PasswordBox registriert seine Password-Eigenschaft mit
einfacher PropertyMetadata statt FrameworkPropertyMetadata, daher ist
sie NICHT standardmäßig zweiseitig gebunden (BindsTwoWayByDefault
liegt bei false). Ohne explizites Mode=TwoWay blieb das ViewModel-
Passwort dauerhaft leer, egal was eingegeben wurde — daher schlug
sowohl die echte Verbindung als auch der Simulator-Testzugang
(127.127.127.127/admin/admin) immer fehl und "Weiter" blieb deaktiviert.
Betraf den Verbindungs-Schritt und den WLAN-Passwort-Schritt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SummaryStepViewModel sammelt alle in den vorherigen Schritten geplanten
Änderungen (WAN/LAN/VLAN/WLAN/Firewall) und zeigt sie im Klartext an.
Erst ein ausdrücklicher Klick auf "Jetzt einrichten" löst etwas aus:
1. RouterBackupService erstellt ein Backup auf dem Gerät selbst
(/system/backup/save) — Download aufs eigene PC ist bewusst nicht
Teil dieses Schritts (bräuchte SFTP zusätzlich zur REST/Binary-API,
als separate Erweiterung zurückgestellt).
2. Alle gesammelten Änderungen werden nacheinander mit Fortschritts-
anzeige angewendet.
3. Bei einem Fehler wird der Backup-Name in der Fehlermeldung genannt,
damit der Nutzer weiß, wie er zurück auf den alten Stand kommt.
Damit ist der komplette Interview-Ablauf (Verbindung → Geräte-Erkennung
→ WAN → LAN → VLAN → WLAN → Firewall → Zusammenfassung → Anwenden)
durchspielbar — auch gefahrlos über den in der letzten Änderung
eingeführten Simulator-Zugang (127.127.127.127 / admin / admin).
Nicht mehr benötigte PlaceholderStepView(Model) entfernt, da jetzt
jeder Schritt eine echte Implementierung hat.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
VlanConfigurator: je VLAN eine eigene VLAN-Schnittstelle auf der
Heimnetz-Bridge mit eigenem Adressbereich und DHCP-Server — für
optionale, vom Heimnetz getrennte Netzwerke (z. B. Gäste, smarte
Geräte). Ohne Einträge bleibt der Schritt wirkungslos.
WirelessConfigurator: WPA2-Sicherheitsprofil anlegen und per
"numbers"-Parameter auf der gewählten WLAN-Schnittstelle aktivieren
(kein zusätzlicher .id-Nachschlage-Aufruf nötig). Der WLAN-Schritt wird
automatisch übersprungen, wenn das Gerät keine WLAN-Schnittstelle hat
(neuer ShouldSkip-Hook in WizardStepViewModelBase, ausgewertet in
MainViewModel.GoNext/GoBack).
FirewallConfigurator: sichere Basisregeln (Router nur aus dem Heimnetz
erreichbar, unangeforderte neue Verbindungen aus dem Internet werden
blockiert) plus optionale Portfreigaben (dstnat + Forward-Allow-Regel
vor der abschließenden Sperrregel), für Geräte, die von außen
erreichbar sein sollen (z. B. Spiele- oder NAS-Server).
Alle drei Schritte sammeln ihre Änderungen weiterhin nur in der
WizardSession — am Gerät wird nichts verändert, bis der noch
ausstehende Zusammenfassungs-Schritt es tut.
Unit-Tests prüfen erzeugte RouterOS-Befehle inkl. Regel-Reihenfolge
(Portfreigaben vor der abschließenden Sperrregel), ohne echtes Gerät.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
DemoRouterOsClient simuliert ein RouterOS-Gerät komplett im Arbeitsspeicher
(keine Netzwerkverbindung) und wird aktiviert, wenn exakt die Zugangsdaten
127.127.127.127 / admin / admin eingegeben werden. So lässt sich der
komplette Interview-Ablauf durchklicken, ohne ein reales MikroTik-Gerät
zu verändern oder überhaupt zu benötigen.
Nur in Debug-Builds erreichbar (#if DEBUG in RouterOsClientFactory),
damit dieser Testzugang nicht in der für Endnutzer veröffentlichten
Version landet.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ConfigurationAction kapselt eine Änderung als Klartext-Beschreibung plus
Anwendungslogik über IRouterOsClient — WanConfigurator und
LanConfigurator bauen daraus die konkreten RouterOS-Befehle:
- WAN: DHCP-Client oder feste IP/Gateway, plus NAT-Masquerade.
- LAN: Bridge mit gewählten Schnittstellen, IP-Adresse, DHCP-Pool,
DHCP-Server, Netzwerk-Eintrag (Gateway/DNS) und Router als
DNS-Weiterleitung fürs Heimnetz.
Beide Wizard-Schritte sammeln die geplanten Änderungen nur in der
WizardSession (WanActions/LanActions) — am Gerät wird weiterhin nichts
verändert, bis der noch ausstehende Zusammenfassungs-Schritt es tut.
Der LAN-Schritt schließt die im WAN-Schritt gewählte Schnittstelle aus
der Anschluss-Auswahl aus und liefert sinnvolle Vorbelegungen
(192.168.88.0/24 u. Ä.), damit man sich weitgehend durchklicken kann.
Unit-Tests prüfen sowohl die erzeugten Beschreibungstexte als auch die
tatsächlich angewendeten RouterOS-Pfade/Parameter über ein
aufzeichnendes Test-Double, ohne echtes Gerät.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
DeviceDiscoveryService liest /system/resource, /system/identity,
/system/routerboard und /interface über IRouterOsClient aus und baut
daraus ein RouterDevice-Modell (inkl. Erkennung, ob WLAN-Schnittstellen
vorhanden sind). Anfragen laufen bewusst sequenziell, da die binäre API
auf einer TCP-Verbindung immer nur einen Befehl gleichzeitig verarbeitet.
WizardSession hält die einmal hergestellte Geräteverbindung über den
gesamten Assistenten hinweg (bisher wurde sie nach dem Verbindungstest
sofort wieder geschlossen). Der Verbindungs-Schritt übergibt den Client
jetzt an die Session statt ihn zu verwerfen; das Hauptfenster schließt
die Verbindung beim Beenden der App sauber.
Neuer Geräte-Erkennungs-Schritt lädt beim Betreten automatisch die
Gerätedaten (WizardStepViewModelBase.OnActivatedAsync-Hook) und zeigt
Modell, RouterOS-Version, Architektur und alle Schnittstellen mit
Status an; bei Fehlern gibt es eine "Erneut versuchen"-Option.
Unit-Tests für DeviceDiscoveryService über ein Test-Double von
IRouterOsClient, ohne echtes Gerät.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
IRouterOsClient als einheitliche Abstraktion (Get/Add/Set/Remove/Execute)
über RouterOS-Menüpfade. RestRouterOsClient spricht die RouterOS-7-REST-API
(JSON über HTTP/HTTPS), BinaryRouterOsClient implementiert das RouterOS-
API-Wortprotokoll direkt (Port 8728/8729) für ältere Geräte.
RouterOsClientFactory probiert REST zuerst und fällt automatisch auf die
Binary-API zurück, damit die Wizard-Schritte protokollunabhängig bleiben.
Verbindungs-Schritt im Wizard testet die Zugangsdaten live gegen das
Gerät und schaltet "Weiter" erst nach erfolgreichem Verbindungstest frei.
Unit-Tests für die Wortkodierung des Binärprotokolls (Längenkodierung,
Mehrwort-Sätze, Satzgrenzen) ohne echtes Gerät.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
.NET 8 Solution mit App (WPF/WPF-UI), Core und Core.Tests.
Generische Schritt-Navigation (MainViewModel) mit Platzhalter-Schritten
als Basis für die kommenden Interview-Schritte.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
adminandClaude Sonnet 5