diff --git a/CHATLOG.md b/CHATLOG.md index d7603e0..3047a42 100644 --- a/CHATLOG.md +++ b/CHATLOG.md @@ -1082,3 +1082,17 @@ Test, WLAN/Bonding/PPPoE-Live-Tests). eingerichteten WLAN. Damit M5 (WLAN-Schritt) und der WLAN-Teil von M10 (Experte-Tab-Schemas) erstmals vollständig gegen Hardware bestätigt — vorher nur der "kein WLAN"-Zweig getestet. + +## Session: Bonding erstmals gegen echte Hardware verifiziert (M10) + +- "Bonding testen" (hAP lite, ether3+ether4 frei) → Experte-Tab → + Interfaces → Bonding, `mode=active-backup`. Erster Versuch schlug + erwartungsgemäß fehl ("ether3 already in bridge" — Ports waren noch + LAN-Bridge-Mitglieder). Nach Entfernen aus der Bridge zweiter + Versuch: App meldete einen Fehler ("Exit-Code 126" ganz ohne + Klartext), `/interface bonding print` am Router zeigte aber `bond1` + bereits korrekt angelegt und laufend — vermutlich eine durch die + Interface-Neuinitialisierung kurz abgerissene SSH-Verbindung, die + die App fälschlich als Fehler wertete. Bonding selbst funktioniert + einwandfrei. "reicht, doku aktualisieren und committen, aber nicht + deployen" → HANDOFF.md aktualisiert, Commit ohne Release-Deploy. diff --git a/HANDOFF.md b/HANDOFF.md index d1e4adb..87bb5e6 100644 --- a/HANDOFF.md +++ b/HANDOFF.md @@ -1636,8 +1636,31 @@ verallgemeinert** (2026-09-16, beim Live-Test von M26 gefunden): manuell durchklicken — M10s Experte-Tab wurde bereits vom Nutzer bestätigt (siehe oben), der Moduswechsel im Wizard noch nicht. 4. M10: ~~WLAN-Schemas (an Gerät mit WLAN-Chip)~~ — erledigt - (2026-09-17, hAP lite). Bonding, PPPoE-Client (mit echten oder - Test-ISP-Zugangsdaten) weiterhin nicht gegen Hardware verifiziert. + (2026-09-17, hAP lite). ~~Bonding~~ — erledigt (2026-09-17, hAP + lite, `ether3`+`ether4`, `mode=active-backup`): `/interface bonding + add` schlug beim ersten Versuch erwartungsgemäß fehl ("ether3 + already in bridge" — beide Ports waren noch LAN-Bridge-Mitglieder, + RouterOS erlaubt einen Port nicht gleichzeitig in Bridge und + Bonding; kein App-Bug). Nach Entfernen aus der Bridge und erneutem + Versuch meldete die App einen Fehler ("Exit-Code 126", ganz ohne + RouterOS-Klartext — ungewöhnlich, normale RouterOS-CLI-Fehler + liefern Text, siehe erster Versuch), aber `/interface bonding + print` am Router zeigte `bond1` bereits korrekt angelegt und + laufend. Vermutlich eine durch die Interface-Neuinitialisierung + beim Bridge-Entfernen kurz abgerissene SSH-Verbindung, die die App + fälschlich als Fehler interpretierte, obwohl der Befehl durchlief + — derselbe Grundsatz wie bei Bug 10/17 ("leere/fehlerhafte Antwort + ist kein Beweis, dass nichts passiert ist"), hier aber in die + andere Richtung: ein gemeldeter Fehler ist kein Beweis, dass nichts + passiert ist. Nicht weiter codeseitig verfolgt (einmalig + beobachtet, kein reproduzierbarer Bug-Report nötig) — bei erneutem + Auftreten zuerst immer den echten Router-Zustand per `print` + verifizieren, nicht der App-Fehlermeldung allein vertrauen. + PPPoE-Client weiterhin nicht gegen Hardware verifiziert — am hAP + lite nicht testbar (2026-09-17: Gerät hängt hinter einem bereits + konfigurierten Router, kein direkter PPPoE-fähiger WAN-Uplink + verfügbar); bräuchte ein + Testgerät direkt am Modem/ISP-Anschluss mit echten Zugangsdaten. 5. ~~Dauer-Editor (`RouterOSFieldSchema.Kind.duration`) auch auf weitere Zeitwert-Felder anwenden~~ — erledigt (2026-09-16): WireGuard-Peer "Keepalive" (Label-Zusatz "(Sekunden)" entfernt, Stepper zeigt Einheit