Christoph Emsenhuber 65a61f7fb6 TP28 ap3 phase2: Selbstabnahme ins Log + Abnahme-Anleitung fuer den Manager ...

Das Skript endete bisher mit `vlan-filtering=yes` und einer Log-Zeile -- ohne
jede Pruefung, ob der CAP wirklich CAP geworden ist.

Neu, Punkt (6) VOR dem Scharfschalten: das Skript zaehlt seine eigenen
wifi-Objekte und schreibt das Ergebnis per `:log info`. Bewusst nicht `:put`
und bewusst nicht danach -- nach `vlan-filtering=yes` kann die Sitzung
abreissen, eine Konsolenausgabe waere dann verloren. Das Log ueberlebt und
ist ueber `/log print where message~"tp28-ap3"` nachlesbar.

Sollwerte am Geraet gemessen, nicht angenommen (ap3 live, 2026-08-30):
  security=0  configuration=0  channel=0  datapath=1  radios-mit-manager=2
🔴 Erwartet ist ausdruecklich NICHT "alles 0": datapath MUSS 1 sein
(dp-caps-slaves). Ein CAP mit 0 Datapaths ist der 14-Stunden-Ausfall vom
2026-08-18 -- Clients assoziieren und bekommen nie DHCP.

security/configuration/channel=0 ist der harte Beleg, dass die Werks-Inline-
Overrides weg sind: CAPsMAN haelt die Credentials, das Geraet haelt nichts.
Gegenprobe am Bestand: ap2 zeigt dieselben 0/0.

Dazu ein Abnahmeblock am Dateiende mit dem Schritt, der sich nicht im Skript
pruefen laesst: `/interface wifi radio print` AM MANAGER muss zwei Zeilen mit
CAP ap3@... zeigen (live: cap-wifi5 + cap-wifi6). Ohne diesen Schritt ist die
Abnahme wertlos, denn `remote-cap print` meldet state=Ok schon beim blossen
Verbinden -- ap1 steht seit 2026-08-30 genau so da: verbunden, gelistet, und
trotzdem funkstill, weil keine Provisioning-Regel matcht.

Am Geraet gegengeprueft: RouterOS kennt KEINEN ternaeren Operator, `a ? b : c`
ist ein syntax error. Verdikt laeuft deshalb ueber :if/:set. Der komplette
Block wurde am ap3 mit :put durchlaufen und meldet "=> OK".

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

2026-08-30 20:44:45 +02:00

8.1 KiB

Raw Blame History

View Raw