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/tp19-ntp-dhcp-option.rsc

@@ -0,0 +1,14 @@
+# NTP-Server per DHCP ausliefern (Christophs Vorschlag 2026-08-18).
+#
+# WARUM DAS BESSER IST ALS PRO GERAET EINZUTRAGEN: bisher kannte nur die
+# MikroTik-Flotte eine Zeitquelle, und die per Hand. Ueber `ntp-server=` im
+# dhcp-server network bekommt **jeder** DHCP-Client den Standort-NTP-Server
+# mitgeliefert (DHCP-Option 42) — ohne dass irgendwo eine IP gepflegt werden
+# muss. Das Gateway des jeweiligen VLAN ist immer .1, also traegt jedes Netz
+# seinen eigenen ein.
+#
+# Voraussetzung ist erfuellt: der Core ist seit heute selbst `synchronized`
+# (tp19-ntp-core-client.rsc) und laeuft als Server (tp19-ntp-core-als-zeitquelle.rsc,
+# inkl. der input-Regel, ohne die er seit TP5 Etappe 4 unerreichbar waere).
+:foreach n in=[/ip dhcp-server network find] do={ :do { /ip dhcp-server network set $n ntp-server=([/ip dhcp-server network get $n gateway]) } on-error={ :log info "tp19ntp: dhcp-option warf" } }
+:log info ("tp19ntp: dhcp-netze-mit-ntp=" . [:tostr [:len [/ip dhcp-server network find where ntp-server!=""]]] . " von " . [:tostr [:len [/ip dhcp-server network find]]])

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]])

routeros/tp7.1-core-ether13-trunk.rsc

@@ -0,0 +1,19 @@
+# TP7.1 — core ether13 (pve) um VLAN10 + VLAN40 erweitern.
+#
+# WOFUER: der SSDP-Relay fuer die macOS-Sonos-App braucht ein Bein in BEIDEN
+# VLANs. SSDP ist link-lokales Multicast mit TTL 1: der M-SEARCH des MacBooks
+# verlaesst VLAN10 nie, die ssdp:alive-NOTIFYs der Sonos verlassen VLAN40 nie.
+# Ein Relay kann nur kopieren, was es selbst hoert — Routing hilft nicht, und
+# `forward accept vlan10<->vlan40` ist laengst offen. Es scheitert VOR dem
+# Verbindungsaufbau, an der Entdeckung.
+#
+# IST-STAND (live 2026-08-18): pve haengt an ether13, das nur `tagged vlan20`
+# traegt (pvid=1). Tags hinzuzufuegen stoert VLAN20 nicht.
+#
+# ⚠️ tagged= wird VOLLSTAENDIG gesetzt, nicht angehaengt — die bestehenden
+# Mitglieder ether1,ether8,ether15 stehen deshalb explizit mit drin. Ein
+# `set tagged=ether13` allein wuerde die anderen entfernen und AP1 sowie den
+# branch-Uplink aus dem VLAN werfen.
+:do { /interface bridge vlan set [find vlan-ids=10 and !dynamic] tagged=ether1,ether8,ether13,ether15 } on-error={ :log info "tp71: vlan10 warf" }
+:do { /interface bridge vlan set [find vlan-ids=40 and !dynamic] tagged=ether1,ether8,ether13,ether15 } on-error={ :log info "tp71: vlan40 warf" }
+:log info ("tp71: ENDE v10-tagged=" . [:tostr [/interface bridge vlan get [find vlan-ids=10 and !dynamic] tagged]] . " v40-tagged=" . [:tostr [/interface bridge vlan get [find vlan-ids=40 and !dynamic] tagged]])