Christoph Emsenhuber
e416b795e8
Die macOS-Sonos-App fand ihre Player nicht. Ursache war nicht die Firewall (MEDIA->MAIN ist offen) und nicht der vermutete Race um den globalen "last SSDP search source"-Slot, sondern die Flagge --ssdpUnicastAddr selbst: multicast-relay.py Z. 630 schreibt die Quelle JEDES SSDP-Pakets an 239.255.255.250:1900 auf <addr>:1901 um (auch NOTIFY), Z. 691 verwirft das Paket dann beim Senden auf eth1, weil 10.40.10.21 nicht im VLAN40-Netz liegt. Der Hinweg lief damit nie. Messung vorher: 0 Pakete via eth1 gegen 308 via eth0 in 20 min, 0x "Received SSDP Unicast" im gesamten Journal seit 2026-08-18. Nachher: M-SEARCH quellerhaltend in VLAN40, HTTP/1.1 200 OK von 10.40.40.193/.195 an beiden MacBook-Beinen, Drop-Log in:vlan40 out:vlan10 = 0. - mcast-relay/multicast-relay.service: reparierte Unit jetzt im Repo (ausgerollt auf LXC 108, Backup /root/multicast-relay.service.bak-20260825) - CLAUDE.md: Gotcha korrigiert, Richtungsbilanz als Erstmessung, Hinweis auf die SO_REUSEPORT-Falle auf Port 1900 und das dual-homed MacBook (.183/.82) - docs/teilprojekte.md: Ist-Stand nachgezogen, TP33 (Fernzugriff) als Stub - docs/teilprojekte-archiv.md: TP7.1-Aussage "--ssdpUnicastAddr ist noetig" widerrufen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
42 lines
2.1 KiB
Desktop File
42 lines
2.1 KiB
Desktop File
# TP7.1 — SSDP-Relay VLAN10 <-> VLAN40 (macOS-Sonos-App)
|
|
#
|
|
# Laeuft auf LXC 108 "mcast-relay" (pve), zweibeinig:
|
|
# eth0 = 10.40.10.21 (VLAN10/MAIN) eth1 = 10.40.40.21 (VLAN40/MEDIA)
|
|
# Ablage im Repo: mcast-relay/multicast-relay.service
|
|
# Ziel auf dem Container: /etc/systemd/system/multicast-relay.service
|
|
# Ausrollen: scp … root@10.40.20.100:/tmp/ && pct push 108 /tmp/multicast-relay.service \
|
|
# /etc/systemd/system/multicast-relay.service && pct exec 108 -- systemctl daemon-reload \
|
|
# && pct exec 108 -- systemctl restart multicast-relay
|
|
#
|
|
# --noMDNS ist WICHTIG: mDNS reflektiert bereits der Core (TP7, mdns-repeat-ifaces).
|
|
# Zweimal zu reflektieren erzeugt Duplikate und Schleifen.
|
|
#
|
|
# 🔴 KEIN --ssdpUnicastAddr (2026-08-25 ausgebaut, war seit 2026-08-18 drin und hat den
|
|
# Hinweg blockiert). Die Flagge schreibt in multicast-relay.py Z. 630 die Quelle JEDES
|
|
# SSDP-Pakets an 239.255.255.250:1900 auf die angegebene Adresse:1901 um — auch NOTIFY.
|
|
# Beim Senden greift dann Z. 691:
|
|
# if srcAddr == ssdpUnicastAddr and not onNetwork(srcAddr, tx['addr'], tx['netmask']): continue
|
|
# 10.40.10.21 liegt nicht im VLAN40-Netz ⇒ die M-SEARCH der App wurde verworfen, BEVOR sie
|
|
# die Player erreichte (Messung: 0 Pakete via eth1 / 308 via eth0 in 20 min, 0 "Received SSDP
|
|
# Unicast" im ganzen Journal). Zusaetzlich ist der Rueckweg im Upstream nur EIN globaler
|
|
# Merkslot (Z. 623 "FIXME: record more than one?").
|
|
# Ohne die Flagge relayt das Werkzeug quellerhaltend; die Player antworten unicast an den
|
|
# echten Sucher und der Core routet das nativ zurueck — forward-Regel "TP5: MEDIA->MAIN"
|
|
# ist offen (in=vlan40 out=vlan10, ohne Portfilter).
|
|
[Unit]
|
|
Description=TP7.1 SSDP-Relay vlan10 <-> vlan40 (macOS-Sonos-App)
|
|
Documentation=docs/teilprojekte.md TP7.1
|
|
After=network-online.target
|
|
Wants=network-online.target
|
|
|
|
[Service]
|
|
ExecStart=/usr/bin/python3 /opt/multicast-relay/multicast-relay.py \
|
|
--interfaces eth0 eth1 \
|
|
--noMDNS \
|
|
--foreground --verbose
|
|
Restart=always
|
|
RestartSec=5
|
|
|
|
[Install]
|
|
WantedBy=multi-user.target
|