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>

docs/teilprojekte-archiv.md

@@ -618,8 +618,12 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
   erweitert (`routeros/tp7.1-core-ether13-trunk.rsc`). Software: `alsmith/multicast-relay` als
   systemd-Unit `multicast-relay.service`.
   - **`--noMDNS` ist Pflicht:** mDNS reflektiert bereits der Core (TP7). Zweimal zu reflektieren
-    erzeugt Duplikate. **`--ssdpUnicastAddr 10.40.10.21`** ist ebenfalls noetig — die Sonos
-    antworten auf einen M-SEARCH per **Unicast**, und diese Antworten muessen zurueckgereicht werden.
+    erzeugt Duplikate. ~~**`--ssdpUnicastAddr 10.40.10.21`** ist ebenfalls noetig — die Sonos
+    antworten auf einen M-SEARCH per **Unicast**, und diese Antworten muessen zurueckgereicht werden.~~
+    🔴 **WIDERRUFEN 2026-08-25:** die Flagge war der Fehler — sie schreibt in `multicast-relay.py` Z. 630
+    die Quelle jedes SSDP-Pakets um, worauf Z. 691 die M-SEARCH beim Senden auf `eth1` **selbst verwirft**
+    (`10.40.10.21` ist nicht im VLAN40-Netz). Der Hinweg lief damit **nie**; ausgebaut, Rückweg wird
+    geroutet (`TP5: MEDIA->MAIN`). Stand + Merkregeln: Ist-Stand in `teilprojekte.md` und Gotcha in `CLAUDE.md`.
 - 🔑 **Warum zwei Beine zwingend sind** (Christophs Frage „vlan40 sollte keinen relay benoetigen?!?"):
   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

docs/teilprojekte.md

@@ -50,9 +50,14 @@ ab jetzt bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)*
   (an core `ether15`), ap2 **`10.40.99.12`** (an branch `ether24`), beide **reine CAPs** —
   `cap enabled=yes`, `discovery-interfaces=vlan99`. Die APs halten **keine eigene WLAN-Config** mehr;
   Kanäle, SSIDs, Security und Steering kommen vom Manager. 802.11r/k/v aktiv, `ft-over-ds=yes`.
-- **SSDP-Relay** (TP7.1 ✅ 08-18): LXC **108 `mcast-relay`** auf pve, zweibeinig `10.40.10.21` (VLAN10) +
-  `10.40.40.21` (VLAN40) — dafür trägt `core ether13` beide VLANs. Die macOS-Sonos-App findet damit ihr
-  System; mDNS macht weiterhin der Core.
+- **SSDP-Relay** (TP7.1, **nachgebessert 08-25**): LXC **108 `mcast-relay`** auf pve, zweibeinig
+  `10.40.10.21` (VLAN10) + `10.40.40.21` (VLAN40) — dafür trägt `core ether13` beide VLANs; mDNS macht
+  weiterhin der Core. **Läuft seit 08-25 ohne `--ssdpUnicastAddr`** — die Flagge verwarf die M-SEARCH
+  der App auf dem Weg nach VLAN40 (Messung: **0 Pakete `via eth1` gegen 308 `via eth0`** in 20 min,
+  **0×** `Received SSDP Unicast` im ganzen Journal seit 08-18). Der Rückweg läuft jetzt **nativ geroutet**
+  über die längst offene Regel `TP5: MEDIA->MAIN`; nachgemessen kommen `HTTP/1.1 200 OK` von
+  `10.40.40.193/.195` an beiden MacBook-Beinen an. Unit liegt im Repo: **`mcast-relay/multicast-relay.service`**,
+  Details als Gotcha in `CLAUDE.md`.
 - **Ausgebaut / gelöscht:** ALLNET-`sw1` und Omada-`sw2` sind **physisch weg** (2026-08-08 bzw. 2026-07-23,
   in Nautobot *Decommissioned*); Omada-Controller + `omada-mcp` gelöscht (2026-07-16); FritzBox 6660 raus
   seit 2026-07-01 (Liwest-Tausch auf Arris). **VLAN1 ist leer** (`/ip arp` auf `bridge` = 0 Einträge,
@@ -1521,6 +1526,25 @@ kann in Ruhe nachziehen.
 - **Abh.:** keine. **Blockiert nichts**, aber TP31 vergibt bereits danach.
 
 
+### TP33 — Sonos aus der Ferne bedienen (VPN/WARP) ▸ 💡 **IDEE, bewusst zurückgestellt** (angelegt 2026-08-25, User-Entscheid „später entscheiden")
+
+- **Auslöser:** beim Sonos-Fall vom 08-25 kam die Frage auf, ob die Player auch **von unterwegs**
+  auffindbar sein sollen. Antwort für jetzt: **nein, später entscheiden** — hier nur festgehalten,
+  damit die Begründung nicht verloren geht.
+- 🔑 **Der Kernsatz:** **SSDP und mDNS queren einen Tunnel nicht von selbst.** Beides ist link-lokal
+  (TTL 1 bzw. Multicast auf `224.0.0.251`), ein WireGuard-/WARP-Tunnel ist ein Punkt-zu-Punkt-Interface
+  ohne Broadcast-Domäne. Es bräuchte also **dieselbe Relay-Bauart wie TP7.1, nur ein zweites Mal** —
+  ein Bein im Tunnel, eines in VLAN40 — plus die passende `forward`-Regel (TP5 ist deny-by-default).
+- ⚖️ **Warum zurückgestellt:** echter Zusatzaufwand für einen **Randfall**. Steuern aus der Ferne geht
+  heute schon über die **Sonos-Cloud-App** und über **HA** (`cf-mesh`/CF-Tunnel), beides ohne Discovery.
+  Fehlt nur die Desktop-App von außen — dafür lohnt der zweite Relay-Strang derzeit nicht.
+- ⚠️ **Nicht mit dem Gegenteil verwechseln:** **mit aktivem WARP findet die App die Player auch lokal
+  nicht** — erwartbares Verhalten, kein Fehler (`ref_warp_local_icmp_trap`, Gotcha in `CLAUDE.md`).
+  Wer den Fernzugriff baut, muss genau diesen Fall mit auflösen.
+- **Abh.:** TP7.1 (Relay-Muster) ✅, TP16.1 (`cf-mesh`) ✅. **Blockiert nichts.**
+
+---
+
 ---
 
 ## Abgeschlossene Teilprojekte ▸ [`teilprojekte-archiv.md`](teilprojekte-archiv.md)