Warum blockieren einige WLAN-Router Multicast-Pakete, die von drahtlos zu drahtlos übertragen werden?

Dies liegt in der Regel an Fehlern in den WLAN-Home-Gateway-Routern (APs) oder manchmal in den Wireless-Client-Chipsätzen / -Treibern / -Software.

Das Senden von Multicasts vom AP an die drahtlosen Clients (dies ist im Standard als "From the Distribution System" oder "FromDS" bekannt) ist schwierig. Daher gibt es viele Möglichkeiten, wie ein Fehler auftreten kann Fehler einführen.

1. Auch wenn das Funkmedium unzuverlässig genug ist, damit 802.11-Unicasts ACKs (ACKs) auf Verbindungsebene benötigen und mehrere Male erneut übertragen werden, wenn kein ACK vorhanden ist, werden FromDS-Multicasts nie ACKs aktiviert, da sie von allen drahtlosen Clients ACKs benötigt werden der AP, die durchaus ein "ACK-Sturm" sein könnte. Stattdessen müssen FromDS-Multicasts mit einer niedrigen Datenrate gesendet werden. mit einem einfacheren, langsameren, einfach zu dekodierenden Modulationsschema, sogar bei niedrigem Signal-zu-Rausch-Verhältnis, das hoffentlich von allen Clients des AP zuverlässig empfangen werden kann. Bei einigen Zugriffspunkten kann der Administrator die Multicast-Rate festlegen, und einige Administratoren setzen diese unwissentlich auf zu hoch, als dass einige ihrer Clients zuverlässig empfangen werden können, wodurch die Multicast-Zustellung für diese Clients unterbrochen wird.
2. Wenn die Verschlüsselung WPA (TKIP) oder WPA2 (AES-CCMP) verwendet wird, müssen FromDS-Multicasts mit einem separaten Verschlüsselungsschlüssel verschlüsselt werden, der allen Clients bekannt ist (dies wird als Gruppenschlüssel bezeichnet).
3. Wenn ein Client das Netzwerk verlässt, oder nur zu jeder vollen Stunde, muss der Gruppenschlüssel so geändert werden, dass der Client, der den Client verlassen hat, keinen Zugriff mehr zum Entschlüsseln der Multicasts hat. Dieser "Group Key Rotation" -Prozeß hat manchmal Probleme. Wenn ein Client den Erhalt des neuen Gruppenschlüssels nicht bestätigt, soll der AP diesen Client de-authentifizieren. Wenn dies jedoch aufgrund eines Fehlers nicht geschieht, hat der Client möglicherweise den falschen Gruppenschlüssel und ist somit "taub" "zu Multicasts, ohne es zu merken.
4. Wenn der "gemischte Modus" von WPA2 aktiviert ist (dh, wenn WPA und WPA2 gleichzeitig aktiviert sind), müssen die FromDS-Multicasts normalerweise mit der TKIP-Verschlüsselung codiert werden, damit alle Clients wissen, wie sie zu decodieren sind .
5. FromDS-Multicasts müssen vom AP in die Warteschlange gestellt und nur dann übertragen werden, wenn alle Clients, die sich für Multicasts interessieren, die Empfänger eingeschaltet haben können. Die Zeit zwischen den "sicherer FromDS-Multicasts" -Perioden wird als "DTIM-Intervall" bezeichnet. Wenn der Zugriffspunkt oder die Clients die DTIM-Intervallverarbeitung fehlerhaft ausführen, kann dies dazu führen, dass Clients Multicasts nicht zuverlässig empfangen können.
6. Einige APs verfügen über Funktionen, um zu verhindern, dass drahtlose Clients direkt miteinander kommunizieren können, und möglicherweise Ihre drahtlosen Gäste daran gehindert werden, andere drahtlose Gäste zu hacken. Diese Funktionen blockieren normalerweise Multicasts von WLAN-Geräten zu anderen WLAN-Geräten und könnten auf naive Weise implementiert werden, sodass sogar Multicasts von LAN zu WLAN blockiert werden.

Das Verrückte ist, dass "ToDS" -Multicasts genauso wie ToDS-Unicasts ausgeführt werden und daher selten brechen. Da ToDS-Multicasts (nicht FromDS-Multicasts) ausreichen, wenn ein Wireless-Client eine DHCP-Lease und ARPs erhält, um sein Standardgateway zu finden, können die meisten Clients eine Verbindung herstellen und im Internet surfen, E-Mails abrufen, selbst bei FromDS Multicasts sind defekt. Viele Leute wissen also nicht, dass sie Multicast-Probleme in ihrem Netzwerk haben, bis sie versuchen, mDNS (auch bekannt als IETF ZeroConf, Apple Bonjour, Avahi usw.) auszuführen.

Ein paar andere Dinge zu beachten, die drahtgebundene zu drahtlose Multicast-Übertragung betreffen:

1. Die meisten LAN-Multicasts, wie z. B. mDNS, verwenden spezielle Multicast-Adressbereiche, die nicht über Router geroutet werden sollen. Da Wi-Fi-fähige Home-Gateways mit aktiviertem NAT als Router gelten, soll mDNS nicht von WAN auf [W] LAN übergehen. Aber es sollte von LAN bis WLAN funktionieren.
2. Da Multicasts über WLAN mit einer niedrigen Datenrate gesendet werden müssen, nehmen sie viel Zeit in Anspruch. Sie sind also "teuer", und Sie möchten nicht zu viele davon haben. Dies ist das Gegenteil von der Funktionsweise von kabelgebundenem Ethernet, bei dem Multicasts "weniger teuer" sind, als dass an jeden Computer separate Unicasts gesendet werden, die sich beispielsweise in einen Multicast-Videostrom einpassen. Aus diesem Grund werden viele Wi-Fi-Zugriffspunkte "IGMP-Snooping" ausführen, um zu beobachten, welche Computer IGMP-Anforderungen (Internet Group Management Protocol) senden, und zeigen damit ihren Wunsch, sich auf einen bestimmten Multicast-Stream einzustellen. Wi-Fi-APs, die IGMP-Snooping ausführen, leiten einige Multicast-Klassen nicht automatisch an das drahtlose Netzwerk weiter, es sei denn, sie sehen einen drahtlosen Client, der versucht, diesen Stream über IGMP zu abonnieren. Die Dokumente, in denen beschrieben wird, wie IGMP-Snooping richtig ausgeführt wird, machen deutlich, dass bestimmte Klassen von Multicasts mit niedriger Bandbreite (mDNS passt in diese Kategorie) immer weitergeleitet werden, auch wenn niemand explizit über IGMP nach ihnen gefragt hat. Es würde mich jedoch nicht wundern, wenn es defekte IGMP-Snooping-Implementierungen gibt, die niemals irgendeine Art von Multicast weiterleiten, bis eine IGMP-Anfrage dafür angezeigt wird.

tl; dr: Bugs. Viele Möglichkeiten für Fehler. Und gelegentlich schlecht entworfene Funktionen und Konfigurationsfehler. Ihre beste Verteidigung ist der Kauf hochwertiger APs von Unternehmen, die darauf achten, dass Multicasts funktionieren. Da Apple Bonjour (mDNS) so sehr liebt, sind die APs von Apple wahrscheinlich die am besten geeigneten Multicasts, und die Wi-Fi-Client-Geräte von Apple sind wahrscheinlich die zuverlässigsten, wenn es darum geht, Multicasts zuverlässig zu empfangen.

@Spiff hat in seiner Antwort einige großartige Punkte gemacht, und ich werde mich hier nicht wiederholen. Es gibt jedoch noch einige andere Antworten und Alternativen, um dieses Problem zu umgehen.

Kurze Antwort? Ich glaube nicht, dass sie immer so oft "blockieren", wie sie es einfach tun, weil sie mit der Faulheit eines Ingenieurs ein bestimmtes Gerät erstellen. Einige haben keine hohe Priorität und andere haben einfach nicht die Zeit, damit es funktioniert.

Im Vergleich zu all den neuen "Features", die das Marketing für den Verkauf dieser Consumer-Grade-Geräte verwendet, ist es nicht ganz oben auf der Prioritätenliste. Es ist eine Eigenschaft, die die meisten Nicht-Technik-versierten Leute nicht kennen Wenn sich nicht ein großer Pool von Eigentümern darüber beschwert, wird es von allen Revisionsaktualisierungen ausgeschlossen.

Wenn Sie ein Gerät suchen, das es unterstützt, führen Sie Ihre Untersuchungen sorgfältig durch und Sie erhalten ein Gerät, das es unterstützt. Wenn Sie ein neues oder gebrauchtes Gerät finden, das OpenWrt oder Tomato von Polarcloud unterstützt, können Sie dies tun versichert, was Sie brauchen.

Viel Glück. :)