From 8f877f18d07a99b853a2100c991ee22ac6b2eaa6 Mon Sep 17 00:00:00 2001 From: Michael Sauer Date: Sun, 20 Sep 2026 02:33:21 +0200 Subject: [PATCH] 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 | 35 +++++++++++++++++++---------------- 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/docs/acceptance-sacn.md b/docs/acceptance-sacn.md index 069d367..66da692 100644 --- a/docs/acceptance-sacn.md +++ b/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.