docs(sacn): Multicast-Ursache geklaert - die Lampe tritt bei, das WLAN filtert

Die Diagnose-Firmware meldet multicast: true, die Pakete kommen trotzdem nicht
an. Damit ist die Firmware raus und die Suche hat eine Richtung: IGMP Snooping
ohne Querier bzw. Multicast-Sperre auf dem IoT-WLAN. Dass mDNS laeuft, ist kein
Gegenbeweis - 224.0.0.0/24 ist von der Filterung per Norm ausgenommen.

docs/acceptance-sacn.md

@@ -31,31 +31,34 @@ eine zweite Lampe geflasht werden muessen. Abgedeckt ist der Fall durch die Host
 (`test_dmx.c`, `test_board_without_rgb_uses_three_slots`) und die board-abhaengige
 Slotgrenze in `test_api.c`.
 
-## Befund: Multicast erreicht die Lampe nicht
+## Befund: Multicast erreicht die Lampe nicht - Ursache liegt im WLAN
 
 Unicast an die Lampen-IP funktioniert durchgaengig. Multicast auf `239.255.0.1` kommt nicht
-an — auch nicht von einem Sender im selben Netz.
+an, auch nicht von einem Sender im selben Netz.
 
-Was dagegen gesichert ist:
+**Geklaert am 2026-09-20 mit einer Diagnose-Firmware** (`0.3.8-63-gfd61f`, Commit fd61f15):
+`system/info` meldet seitdem `sacn.multicast`, also das Ergebnis von `IP_ADD_MEMBERSHIP`.
+Die Lampe liefert **`multicast: true`** - der Beitritt zur Gruppe gelingt. Die Pakete kommen
+trotzdem nicht an. Damit liegt es nicht an der Firmware, sondern am Netz: das WLAN reicht
+die Gruppe `239.255.0.1` nicht an die Lampe weiter.
 
-- Die Lampen empfangen Multicast grundsaetzlich: Alle sieben im Netz antworten auf eine
-  mDNS-Anfrage an `224.0.0.251`.
-- Der Unterschied liegt also im Gruppenbeitritt fuer `239.255.0.1`, nicht im Empfang an sich.
-- Das SDK programmiert beim IGMP-Beitritt einen Hardware-Multicast-Filter
-  (`ethernetif_igmp_mac_filter` -> `tls_hw_set_multicast_key`). Die Funktion selbst liegt in
-  einer vorkompilierten SDK-Bibliothek und ist im Quelltext nicht einsehbar.
-- `nl_sacn.c` ignoriert das Ergebnis von `IP_ADD_MEMBERSHIP` bewusst (ein fehlgeschlagener
-  Beitritt soll den Unicast-Empfang nicht verhindern). Genau deshalb ist derzeit nicht
-  feststellbar, ob der Beitritt scheitert.
+Dass mDNS funktioniert, widerspricht dem nicht: `224.0.0.251` liegt im link-lokalen Bereich
+`224.0.0.0/24`, den Switches und Access Points per Norm von der IGMP-Filterung ausnehmen und
+immer fluten. `239.255.0.1` unterliegt dagegen der Filterung.
 
-Naechster Schritt zur Klaerung: das Ergebnis des Beitritts sichtbar machen (Konsolenzeile
-oder Feld in `system/info`), neu aufspielen und nachsehen. Erst dann laesst sich sagen, ob
-die Lampe nicht beitritt oder das WLAN die Gruppe nicht weiterreicht.
+Anzusehen waeren im UniFi-Setup fuer das IoT-Netz:
+
+- WLAN-Einstellungen: "Multicast and Broadcast Control" bzw. "Block LAN to WLAN Multicast
+  and Broadcast" - ist das aktiv, faellt die Gruppe weg, solange sie nicht ausdruecklich
+  erlaubt ist.
+- Netzwerk-Einstellungen: IGMP Snooping - entweder auf diesem VLAN abschalten (dann wird
+  geflutet) oder sicherstellen, dass ein Querier laeuft. Snooping ohne Querier ist der
+  klassische Weg, Multicast unbemerkt verschwinden zu lassen.
 
 Zwei Fehlversuche auf dem Weg dorthin, damit sie niemand wiederholt:
 
 - Der erste Multicast-Test lief vom Mac (192.168.1.131) gegen eine Lampe in 192.168.2.x.
-  Multicast wird zwischen den Netzen nicht geroutet — der Test konnte gar nicht gelingen.
+  Multicast wird zwischen den Netzen nicht geroutet - der Test konnte gar nicht gelingen.
 - Der zweite liess den Pi in die Gruppe eintreten und an sie senden. Ein Access Point
   schickt einem Sender seine eigenen Multicast-Frames nicht zurueck; das Ergebnis war
   aussagelos, nicht negativ.