From 2c7ebac6d1aa44ef022a174888e837448d4d3705 Mon Sep 17 00:00:00 2001 From: Michael Sauer Date: Sun, 20 Sep 2026 03:15:17 +0200 Subject: [PATCH] docs(sacn): Multicast weiter eingekreist - vier Theorien ausgeschlossen Nicht die Ursache: der netif-Ausstieg im SDK-Filter (tls_get_netif liefert das STA-Interface), fehlender Multicast-Empfang (mDNS kommt an), fehlendes Multicast-Senden (die mDNS-Ankuendigung der Lampe ist ueber die Luft sichtbar), die zweite Filterebene tls_filter_mcast_mac (gebaut, aufgespielt, getestet, zurueckgenommen) und Stromsparen/DTIM. Uebrig bleibt das Indiz, dass die Lampe keine IGMP-Meldung sendet - beweisbar nur per serieller Konsole oder Monitor-Mitschnitt. --- docs/acceptance-sacn.md | 36 ++++++++++++++++++++++++++++++------ 1 file changed, 30 insertions(+), 6 deletions(-) diff --git a/docs/acceptance-sacn.md b/docs/acceptance-sacn.md index 1ad779a..70c6f33 100644 --- a/docs/acceptance-sacn.md +++ b/docs/acceptance-sacn.md @@ -73,13 +73,37 @@ if (netif != tls_get_netif()) aus - sie meldet also Erfolg, OHNE den Filter gesetzt zu haben, wenn die Schnittstelle nicht die vom SDK als aktuell gefuehrte ist. Dann nimmt der Chip die Frames nie an. -Naechste Schritte, wenn es weitergeht: +### Was in derselben Nacht noch geprueft und AUSGESCHLOSSEN wurde -1. Serielle Konsole an eine Lampe haengen und mitlesen, was beim Beitritt passiert. -2. `imr_interface` einmal mit `INADDR_ANY` statt der STA-IP versuchen - das aendert, welches - netif lwIP waehlt, und koennte den Ausstieg oben umgehen. -3. `sacn.multicast` ehrlicher machen: aktuell behauptet es einen Erfolg, den das SDK nur - zurueckmeldet, aber nicht garantiert. +- **Der Ausstieg in `ethernetif_igmp_mac_filter` greift nicht.** `tls_get_netif()` + (`sdk/Src/Network/lwip2.0.3/netif/wm_ethernet.c:473`) liefert `nif`, und das ist das + STA-Interface - genau das, auf dem der Beitritt laeuft. `netif != tls_get_netif()` ist + also falsch, der Hardware-Schluessel wird gesetzt. Meine erste Theorie war damit falsch. +- **Die Lampe empfaengt Multicast.** Sie beantwortet eine mDNS-Anfrage, die ausschliesslich + als Multicast an 224.0.0.251 ging. +- **Die Lampe sendet Multicast.** Nach einem Neustart sah der Pi ihre mDNS-Ankuendigung auf + 224.0.0.251 - Multicast von WLAN-Geraet zu WLAN-Geraet ist also sichtbar und die Messung + taugt. +- **Im IGMP-Mitschnitt schweigt die Lampe.** Querier-Abfragen (vom Gateway) und Meldungen + anderer Geraete sind zu sehen, von der Lampe kommt weder eine Beitrittsmeldung noch eine + Antwort auf die Abfrage. ABER: Bei aktivem Snooping leiten Switches Meldungen nur Richtung + Router weiter - das Schweigen ist damit ein Indiz, kein Beweis. +- **`tls_filter_mcast_mac(gruppen_mac, 1)` nach dem Beitritt aendert nichts.** Die zweite, + im SDK-Header dokumentierte Filterebene wird aus dem Quelltext nie aufgerufen; sie + ausdruecklich zu oeffnen wurde gebaut, aufgespielt und getestet - Multicast kam weiterhin + nicht an. Der Versuch wurde danach zurueckgenommen, die Lampe laeuft wieder auf `main`. +- **Stromsparen/DTIM scheidet aus**: Waere das die Ursache, kaeme auch mDNS nicht an. + +### Naechste Schritte, wenn es weitergeht + +1. Serielle Konsole an eine Lampe haengen: sieht man beim Beitritt einen Sendeversuch der + IGMP-Meldung? Das ist die einzige Messung, die das verbleibende Indiz zum Beweis macht. +2. Mitschnitt im Monitor-Modus (Laptop auf demselben Kanal) - zeigt, was wirklich ueber die + Luft geht, unabhaengig davon, was der AP weiterreicht. +3. IGMP-Snooping einmal ganz aus und dabei mitschneiden: dann fluten Switches auch + IGMP-Meldungen, und das Schweigen der Lampe waere eindeutig zu belegen oder zu widerlegen. +4. `sacn.multicast` ehrlicher benennen: es meldet den Rueckgabewert von + `IP_ADD_MEMBERSHIP`, nicht die tatsaechliche Empfangsbereitschaft. Zwei Fehlversuche auf dem Weg dorthin, damit sie niemand wiederholt: