Files

Christoph Emsenhuber 03f328f043 TP3 📶 ✅ As-built finalisiert: 5 dirtyvader-SSIDs live, Kanal-Plan + Sonos-Diagnose

- ft=no auf sec-media (802.11r bricht Sonos), ft-over-ds=no
- Kanal-Plan non-DFS/überlappungsfrei: ap1 ch36+ch1, ap2 ch149+ch11
  (Auto-Channel hatte beide APs auf 5500-DFS/2437 = Co-Channel gelegt)
- tp3-capsman.rsc: Channel-Frequenzen, ap1-Interface-Override, Verifikation 2026-06-18
- obsolete capsman-flat-asbuilt/ap1-manager/ap2-cap entfernt (von tp3-capsman.rsc ersetzt)
- teilprojekte.md TP3 → ✅; Sonos-Split-Diagnose in tp7-mdns.md + sonos-inventar.md
  (7 WLAN-Sonos noch auf FB-WLAN/VLAN1 → "selektiv je Netz", kein mDNS-Defekt)

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

2026-06-18 01:11:41 +02:00

3.4 KiB

Raw Blame History

TP7 — Media-Discovery (mDNS) für VLAN 40 (As-built, 2026-06-17)

Ziel: Clients auf MAIN (VLAN 10) sollen Mediageräte auf MEDIA (VLAN 40) finden (AirPlay/Bonjour, Sonos) — über VLAN-Grenzen hinweg, ohne beide VLANs zu mischen.

Realzustand bei Start

MAIN (vlan10): MacBookAir 10.40.10.200
MEDIA (vlan40): 2× SonosZP 10.40.40.199 / .200
Inter-VLAN-Forwarding noch komplett offen (TP5 Deny-by-default existiert noch nicht).

Umsetzung — nativer mDNS-Repeater (RouterOS 7.16+, hier 7.23.1)

Leitsatz „nativ vor Container" → kein Reflector-Container, sondern Built-in:

/ip/dns/set mdns-repeat-ifaces=vlan10,vlan40

Der Router-DNS-Dienst (läuft bereits, allow-remote-requests=yes) spiegelt mDNS (224.0.0.251:5353) zwischen den gelisteten Interfaces. Reversibel: Feld leeren (mdns-repeat-ifaces="").

Wichtig (entschärft die TP5-Abhängigkeit): Der Repeater re-originiert die mDNS-Pakete vom Router selbst (input→output), kein Client-zu-Client-forward. → Deny-by-default im forward-Chain blockt die Discovery nicht.

Diagnose 2026-06-18 — „Sonos selektiv je Netz" ist KEIN mDNS-Defekt

Nach TP3 gemeldet: Sonos erscheinen nur teilweise. Ursache nicht der Repeater (intakt: vlan10,vlan40), sondern der gespaltene Sonos-Household: 4 Sonos auf VLAN 40, 7 noch auf dem FritzBox-WLAN (VLAN 1). Der Repeater spiegelt nur vlan10↔vlan40 → MAIN-Client sieht nur die VLAN40-Hälfte, FB-WLAN-Client nur die VLAN1-Hälfte. Fix = die 7 WLAN-Sonos auf dirtyvader-media (VLAN 40) migrieren (s. sonos-inventar.md), dann ist der Household geschlossen und MAIN sieht über den Repeater alle. VLAN1 bewusst NICHT in den Repeater aufnehmen (FB-Transit, temporär) — der saubere Weg ist die Migration.

Verifikation

Config aktiv bestätigt: mdns-repeat-ifaces: vlan10,vlan40 (/ip/dns/get).
Passive Torch (dst 224.0.0.251 auf vlan10/vlan40) im Sampling-Fenster leer → erwartbar, mDNS ist sporadisch ohne aktiven Client-Query.
Funktionaler Test (definitiv): Auf dem MAIN-Client (MacBook, vlan10) die Sonos-App bzw. AirPlay-Ziele öffnen → die beiden SonosZP müssen erscheinen. Dann ggf. Torch erneut: dann ist mDNS-Reflexion auf vlan10 sichtbar.

Offene Punkte / Anschluss an andere TPs

TP5 (Firewall) — was bei Deny-by-default ergänzt werden MUSS

forward-Chain: MAIN↔MEDIA-Nutzdaten erlauben (AirPlay TCP 7000 + dyn. Ports, Sonos 1400/3400/4444 etc.). TP5 plant ohnehin „MAIN↔MEDIA allow (+mDNS)". Ohne diese Regel funktioniert zwar die Discovery, aber nicht das Streamen/Steuern.
input-Chain: Beim Härten des Router-Inputs UDP 5353 von vlan10 & vlan40 an den Router (224.0.0.251) offenlassen — sonst empfängt der Repeater nichts mehr.

SSDP / Chromecast (optional, deferred)

Der native Repeater deckt nur mDNS ab. Reines SSDP (UDP 1900, ältere Cast-/DLNA-Geräte) bräuchte einen Reflector-Container — laut HW-Constraint (128 MB Flash, kein USB) nicht am hAP, sondern auf NAS/pve. Sonos & AirPlay laufen über mDNS → für den aktuellen Gerätebestand nicht nötig. Bei Bedarf später.

IOT (VLAN 30)

Bewusst nicht in den Repeater aufgenommen (TP7-Scope = MAIN↔MEDIA). Smart-Home- Discovery ist HA-Sache. Erweiterung wäre mdns-repeat-ifaces=vlan10,vlan30,vlan40.

Rollback

/ip/dns/set mdns-repeat-ifaces=""

3.4 KiB Raw Blame History Unescape Escape