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