NTP-Governance, SSDP-Relay live, WLAN-Config zurueck unter Drift-Kontrolle

92/92 compliant, 0 Drifts (vorher 71/76 bei 19 Rules -- jetzt 23 Rules).

NTP: die Wurzel war doppelt. Der Core hatte keinen eigenen Client, UND sein
Server hielt Stratum 16 fest, weil er eingeschaltet wurde, bevor der Client
synchron war. Der Test, der es aufgeklaert hat: branch einmal auf
at.pool.ntp.org zeigen lassen -- 20 Sekunden bis synchronized, also war der
Client heil und der Server schwieg. Jetzt im Template, per DHCP-Option 42 an
alle Clients ausgeliefert und mit der Rule system-ntp ueberwacht.

TP7.1: SSDP-Relay laeuft als LXC 108 auf pve, zweibeinig in VLAN10+40.
User-bestaetigt: "sonos ist da!". core ether13 traegt dafuer jetzt beide VLANs.

TP28: die APs trugen noch die komplette Standalone-WLAN-Config aus TP3 --
wirkungslos, aber sie haette als Soll totes Zeug zur Absicht erklaert.
Abgeraeumt, ohne einen einzigen Client zu verlieren (30 vorher, 30 nachher).
Die fuenf wifi-*-Features haengen jetzt am Core, dazu drei neue Rules
(wifi-capsman, wifi-provisioning, wifi-cap).

Gelernt: [find !dynamic] ist auf /interface wifi configuration ein
SYNTAXFEHLER, kein Filter -- der erste Anlauf aenderte nichts und meldete
trotzdem "Plan Completed".

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

routeros/tp28-ap-wifi-reste-abraeumen.rsc

@@ -0,0 +1,34 @@
+# 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]])