Christoph Emsenhuber e416b795e8 TP7.1 nachgebessert: --ssdpUnicastAddr raus, SSDP-Hinweg repariert ...

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>

2026-08-25 18:28:53 +02:00

2.1 KiB

Raw Blame History

View Raw