64 lines
4.3 KiB
Plaintext
64 lines
4.3 KiB
Plaintext
# TP28 — die toten Standalone-WLAN-Objekte vom CAP abraeumen.
|
|
#
|
|
# BEFUND (2026-08-18): ap1 und ap2 tragen weiterhin die komplette WLAN-Config aus
|
|
# dem TP3-Standalone-Aufbau — 2 channel, 6 datapath, 6 security, 7 configuration,
|
|
# 1 steering. Seit dem CAPsMAN-Cutover (2026-08-17) kommt all das vom Manager und
|
|
# wird auf dem CAP als DYNAMISCHES Interface angelegt; die statischen Objekte sind
|
|
# wirkungslos. Sie im Template als Soll zu rendern hiesse, totes Zeug zur Absicht
|
|
# zu erklaeren — dasselbe Argument, mit dem in TP26 die defconf-Firewallregeln der
|
|
# APs nicht ins Template geschrieben wurden.
|
|
#
|
|
# ⚠️ REIHENFOLGE IST PFLICHT: `configuration` referenziert security, datapath und
|
|
# channel. Wer die Referenzierten zuerst loescht, bekommt einen Fehler und laesst
|
|
# einen Teil-Zustand zurueck (Netmiko-Lehre aus TP5 Etappe 1).
|
|
#
|
|
# 🔴 `[find !dynamic]` WIRFT HIER EINEN SYNTAXFEHLER (2026-08-18 aufgeschlagen):
|
|
# `/interface wifi configuration` und Geschwister haben gar keine `dynamic`-
|
|
# Eigenschaft -- die gibt es nur auf `/interface wifi` selbst. Der erste Versuch
|
|
# lief deshalb komplett in die on-error-Zweige und aenderte NICHTS, meldete aber
|
|
# "Plan Completed". Wieder ein Beleg: nur die Gegenpruefung am Geraet zaehlt.
|
|
# Richtig ist hier schlicht `[find]` -- diese Objekte sind ausnahmslos statisch.
|
|
#
|
|
# ⚠️ Die dynamischen VAPs (`/interface wifi find dynamic`) werden NICHT angefasst.
|
|
# Sie tragen ihre Werte inline (datapath.vlan-id=..., SSID im Kommentar) und
|
|
# referenzieren kein lokales Objekt -- am Geraet gegengeprueft.
|
|
#
|
|
# Erwartung: die Client-Verbindungen bleiben unberuehrt, weil kein einziges dieser
|
|
# Objekte von einem laufenden VAP referenziert wird.
|
|
:do { /interface wifi configuration remove [find] } on-error={ :log info "tp28c: configuration warf" }
|
|
:do { /interface wifi steering remove [find] } on-error={ :log info "tp28c: steering warf" }
|
|
:do { /interface wifi security remove [find] } on-error={ :log info "tp28c: security warf" }
|
|
:do { /interface wifi datapath remove [find] } on-error={ :log info "tp28c: datapath warf" }
|
|
:do { /interface wifi channel remove [find] } on-error={ :log info "tp28c: channel warf" }
|
|
|
|
:log info ("tp28c: ENDE cfg=" . [:tostr [:len [/interface wifi configuration find]]] . " sec=" . [:tostr [:len [/interface wifi security find]]] . " dp=" . [:tostr [:len [/interface wifi datapath find]]] . " ch=" . [:tostr [:len [/interface wifi channel find]]] . " st=" . [:tostr [:len [/interface wifi steering find]]] . " cap-enabled=" . [:tostr [/interface wifi cap get enabled]])
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# 🔴 NACHTRAG 2026-08-18, nach rund 14 h Ausfall von IOT + MEDIA:
|
|
# Die Annahme oben ("Client-Verbindungen bleiben unberuehrt") stimmte — das
|
|
# Skript hat den Ausfall NICHT ausgeloest. Die Bruchstelle liegt frueher, im
|
|
# CAPsMAN-Cutover selbst (2026-08-17): dabei wurde `/interface wifi cap
|
|
# slaves-datapath` nie gesetzt. Genau dieses Feld ist das EINZIGE, was die vom
|
|
# Manager erzeugten Slave-VAPs lokal in die Bridge haengt; der Manager schickt
|
|
# `datapath.bridge=bridge` zwar mit, der CAP uebernimmt davon aber nur die
|
|
# vlan-id. Seit dem Cutover assoziierten IOT-/MEDIA-Clients also sauber, ihre
|
|
# Frames gingen nirgendwo hin — am Core kam auf vlan30/vlan40 kein einziges
|
|
# Paket an. Die Master-Radios (wifi1/wifi2 = dirtyvader-main) sind statische
|
|
# Bridge-Ports und liefen weiter, deshalb sah das WLAN von aussen "halb ok" aus.
|
|
# Belege: `slaves-datapath` kommt in keiner Provisionierungs-Referenz vor
|
|
# (routeros/.secrets/ap*-prov-base.rsc), und die letzten IOT-/MEDIA-Leases
|
|
# stammen vom Abend des 2026-08-17.
|
|
#
|
|
# Dieses Skript hat den Schaden aber ZEMENTIERT: mit den geloeschten datapath-
|
|
# Objekten gab es lokal nichts mehr, worauf `slaves-datapath` haette zeigen
|
|
# koennen. Der naheliegende Ein-Zeilen-Fix war damit nicht mehr moeglich.
|
|
#
|
|
# Reparatur (ap1 und ap2, live 2026-08-18, seither im Template als Soll):
|
|
# /interface wifi datapath add name=dp-caps-slaves bridge=bridge
|
|
# /interface wifi cap set slaves-datapath=dp-caps-slaves
|
|
# Das Objekt traegt bewusst KEINE vlan-id — die kommt pro VAP vom Manager.
|
|
#
|
|
# LEHRE: `remove [find]` ohne Ruecksicht auf Referenzen aus /interface wifi cap.
|
|
# Vor dem Abraeumen pruefen: :put [/interface wifi cap get slaves-datapath]
|
|
# ---------------------------------------------------------------------------
|