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

@@ -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: