Christoph Emsenhuber b1ddd3574d TP26: defconf-Firewall auf beiden APs abgeraeumt — --assert hat zwei Fehlschlaege gefangen ...

11 statische Werksregeln je AP entfernt (input-seal, fasttrack, ipsec, sogar
"accept to local loopback (for CAPsMAN)"). Ein reiner AP routet nicht; die
Regeln waren inert. Mgmt haengt an /ip service (TP16.1), nicht an der
input-Kette — kein Lockout-Risiko. ap2 danach: 2 Radios running, 7 Clients.

Der eigentliche Wert dieser Session steckt in den zwei Fehlschlaegen davor,
die --assert bei seinem ERSTEN echten Einsatz gefangen hat. Beide meldeten
"Plan-Status: Completed":

1. `remove [find]` erfasst die DYNAMISCHE Fasttrack-Dummy-Regel mit. RouterOS
   verweigert deren Entfernung, das ganze Kommando wirft, es wird NICHTS
   entfernt. Log: "tp26: remove warf".

2. Der naheliegende Fix `[find !dynamic]` ist ein SYNTAXFEHLER — korrekt ist
   `[find where !dynamic]`. Und Syntaxfehler schlagen beim Parsen zu:
   `:do {} on-error={}` faengt sie NICHT, der Handler laeuft nie. Symptom
   deshalb besonders tueckisch — kein Fehler im Log, keine Wirkung,
   Plan "Completed". Merkregel: on-error schuetzt vor Laufzeitfehlern,
   nicht vor Tippfehlern.

Ohne --assert waeren beide unbemerkt geblieben. Genau der Fehlermodus, den
Christoph mit "einstellungen werden nicht uebernommen, dir faellt das nicht
mal auf" benannt hat.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-17 15:48:23 +02:00

2.8 KiB

Raw Blame History

View Raw