Christoph Emsenhuber
c709c9da6b
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>
20 lines
1.4 KiB
Plaintext
20 lines
1.4 KiB
Plaintext
# 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]])
|