4.4 KiB
TP7 — Media-Discovery (mDNS) für VLAN 40 (As-built, 2026-06-17)
⚠️ Update 2026-07-03 (TP7.2) — supersedes Teile dieses As-builts:
- Aktuelle Repeater-Config:
mdns-repeat-ifaces=vlan10,vlan20,vlan40,vlan30,vlan90,bridge(nicht mehrvlan10,vlan40). Erweitert um vlan20 (HA-Discovery, 2026-07-02), vlan30 (IOT/P750W), vlan90 (GUEST, permanent) undbridge(=VLAN-1-untagged, temporär) am 2026-07-03.- Damit obsolet: die Aussage unten „VLAN 1 bewusst NICHT in den Repeater aufnehmen". VLAN 1 (
bridge) ist jetzt drin, weil HA noch auf10.40.41.105(VLAN 1) hängt und die Sonos entdecken können muss.- GUEST-Firewall (permanent):
input accept udp/5353 vlan90+forward accept vlan90↔vlan40(ganzes MEDIA).- Trade-off bewusst: flacher Repeater → GUEST sieht auch MAIN/INFRA/IOT-mDNS-Announcements (Discovery-Leak).
- HA-Sonos: primär via static
hosts:+advertise_addr(SSDP-abhängige Integration, s.sonos-inventar.md); derbridge-Repeater ist zusätzliche Redundanz. Details → TP7.2 inteilprojekte.md.
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.251auf 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=""