Warum blockieren einige WLAN-Router Multicast-Pakete, die von kabelgebunden zu kabellos wechseln?

Ich habe mit Dutzenden von WLAN-Routern für Privatanwender gearbeitet, und sie waren damit wirklich erfolgreich, obwohl es anscheinend besser wird.

Beispiel der Ausgabe:

1. Ein mit mDNS erkennbares Gerät wird über ein Kabel mit dem Router verbunden.
2. Ein anderes Gerät, das über WLAN mit dem Router verbunden ist, versucht, das Gerät in Schritt 1 zu erkennen.
3. Pakete vom Gerät über WLAN gelangen nicht zum kabelgebundenen Gerät. Wenn dies der Fall ist, gelangen vom kabelgebundenen Gerät gesendete Pakete nicht zum kabellosen Gerät.

Viele Router haben Einstellungen, mit denen dies funktioniert.

Siehe http://community.linksys.com/t5/Wireless-Routers/WRT120N-WLAN-Issues/td-p/400073 und http://forums.verizon.com/t5/FiOS-Internet/Communication-between-wired -und-drahtloses-Netzwerk-auf-actiontec / td-p / 461359 für Beispiele.

Gibt es eine Liste, die inkompatibel ist? Was ist die Ursache? Nur ein Fehler im Router?

Dies liegt normalerweise an Fehlern in den WLAN-Routern (APs) für Heim-Gateways oder manchmal an den Chipsätzen / Treibern / der Software für drahtlose Clients.

Unter Wi-Fi ist das Senden von Multicasts vom AP an die drahtlosen Clients (im Standard als "From the Distribution System" oder "FromDS" bezeichnet) schwierig stelle Bugs vor.

1. Obwohl das Funkmedium so unzuverlässig ist, dass 802.11-Unicasts Bestätigungen auf Verbindungsebene (Link Level Acknowledgements, ACKs) aufweisen und mehrmals erneut übertragen werden müssen, wenn keine ACK vorhanden ist, werden FromDS-Multicasts niemals ACK-fähig, da sie von allen drahtlosen Clients ACK-fähig sein müssten des AP, der 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, das hoffentlich von allen Clients des AP zuverlässig empfangen werden kann. Bei einigen Zugriffspunkten kann der Administrator die Multicast-Rate festlegen, und bei einigen Administratoren ist sie unabsichtlich zu hoch, damit einige ihrer Clients zuverlässig empfangen und die Multicast-Übermittlung an diese Clients unterbrechen können.
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 aus gutem Grund jede Stunde, muss der Gruppenschlüssel geändert werden, damit der Client, der das Netzwerk verlassen hat, keinen Zugriff mehr hat, um die Multicasts zu entschlüsseln. Dieser Vorgang "Gruppentastendrehung" weist manchmal Probleme auf. Wenn ein Client den Empfang des neuen Gruppenschlüssels nicht bestätigt, soll der AP diesen Client de-authentifizieren. Wenn er dies jedoch aufgrund eines Fehlers nicht tut, könnte ein Client den falschen Gruppenschlüssel haben und somit "taub" sein "zu Multicasts, ohne es zu merken.
4. Wenn der gemischte WPA2-Modus aktiviert ist (d. H. Wenn sowohl WPA als auch WPA2 gleichzeitig aktiviert sind), müssen die FromDS-Multicasts normalerweise mit der TKIP-Verschlüsselung codiert werden, damit alle Clients garantiert wissen, wie sie zu decodieren sind .
5. FromDS-Multicasts müssen vom AP in die Warteschlange gestellt und nur zu Zeiten gesendet werden, zu denen von allen Clients, die sich für Multicasts interessieren, erwartet werden kann, dass ihre Empfänger eingeschaltet sind. Die Zeit zwischen den "sicher zu übertragenden FromDS-Multicasts" wird als "DTIM-Intervall" bezeichnet. Wenn der Zugriffspunkt oder die Clients ihre DTIM-Intervallbehandlung vermasseln, kann dies dazu führen, dass Clients Multicasts nicht zuverlässig empfangen können.
6. Einige APs verfügen über Funktionen, die verhindern, dass drahtlose Clients direkt miteinander kommunizieren können, um möglicherweise zu verhindern, dass Ihre drahtlosen Gäste Ihre anderen drahtlosen Gäste hacken. Diese Funktionen blockieren normalerweise Multicasts von WLAN-Geräten zu anderen WLAN-Geräten und können auf eine naive Weise implementiert werden, die sogar Multicasts von LAN zu WLAN blockiert.

Das Verrückte ist, "ToDS" -Multicasts werden genau wie ToDS-Unicasts erstellt und brechen daher nur selten zusammen. Und da ToDS-Multicasts (keine FromDS-Multicasts) alles sind, was benötigt wird, wenn ein drahtloser Client eine DHCP-Lease und ARPs erhält, um sein Standard-Gateway zu finden, können die meisten Clients eine Verbindung herstellen und im Internet surfen, E-Mails abrufen usw., auch wenn FromDS verwendet wird Multicasts sind kaputt. Viele Leute merken also erst, dass sie Multicast-Probleme in ihrem Netzwerk haben, wenn sie versuchen, mDNS (auch bekannt als IETF ZeroConf, Apple Bonjour, Avahi usw.) auszuführen.

Ein paar andere Dinge zu beachten, in Bezug auf kabelgebundene zu kabellosen Multicast-Übertragungen:

1. Die meisten LAN-Multicasts, wie z. B. mDNS, werden mit speziellen Multicast-Adressbereichen ausgeführt, die nicht für das Routing über Router vorgesehen sind. Da Wi-Fi-fähige Heimgateways mit aktiviertem NAT als Router gelten, soll mDNS nicht von WAN zu [W] LAN wechseln. Aber es sollte von LAN zu WLAN funktionieren.
2. Da Multicasts über WLAN mit einer geringen Datenrate gesendet werden müssen, benötigen sie viel Sendezeit. Sie sind also "teuer" und Sie möchten nicht zu viele davon haben. Dies ist das Gegenteil von der Situation bei kabelgebundenem Ethernet, bei dem Multicasts "kostengünstiger" sind als das Senden separater Unicasts an jeden Computer, zum Beispiel "Einstellen eines Multicast-Videostreams". Aus diesem Grund überwachen viele Wi-Fi-Zugriffspunkte mithilfe von "IGMP-Snooping", welche Computer IGMP-Anforderungen (Internet Group Management Protocol) senden, und möchten sich auf einen bestimmten Multicast-Stream einstellen. Wi-Fi-Zugriffspunkte, die IGMP-Snooping ausführen, leiten einige Klassen von Multicasts nur dann automatisch an das drahtlose Netzwerk weiter, wenn ein drahtloser Client versucht, diesen Stream über IGMP zu abonnieren. Die Dokumente, die beschreiben, wie IGMP-Snooping richtig durchgeführt wird, machen deutlich, dass bestimmte Klassen von Multicasts mit geringer Bandbreite (mDNS passt in diese Kategorie) immer weitergeleitet werden sollen, auch wenn niemand explizit über IGMP danach gefragt hat. Es würde mich jedoch nicht wundern, wenn es defekte IGMP-Snooping-Implementierungen gibt, die keinerlei Multicast weiterleiten, bis eine IGMP-Anforderung dafür eingeht.

tl; dr: Bugs. Viele Möglichkeiten für Fehler. Und gelegentlich schlecht gestaltete Funktionen und Konfigurationsfehler. Ihre beste Verteidigung besteht darin, hochwertige APs von Unternehmen zu kaufen, die darauf achten, dass Multicasts funktionieren. Da Apple Bonjour (mDNS) so liebt, sind die APs von Apple wahrscheinlich am beständigsten darin, Multicasts zuverlässig zu übermitteln, und die Wi-Fi-Client-Geräte von Apple sind wahrscheinlich am beständigsten darin, Multicasts zuverlässig zu empfangen.

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

Kurze Antwort? Ich glaube nicht, dass sie immer so viel "blockieren", wie sie es einfach "nicht tun, von Anfang an", weil die Ingenieure faul sind, ein bestimmtes Gerät zu erstellen. Einige haben es nicht als hohe Priorität, und andere haben einfach nicht die Zeit, es zum Laufen zu bringen.

Es steht nicht ganz oben auf der Prioritätenliste im Vergleich zu all den neuen "Funktionen", die Marketing für den Verkauf dieser Geräte für Endverbraucher verwendet, und es ist eine Funktion, von der die meisten technisch nicht versierten Leute keine Ahnung haben es sei denn, ein großer Pool von Eigentümern beschwert sich darüber, wird es von Revisionsaktualisierungen ausgeschlossen.

Wenn Sie ein Gerät suchen, das es unterstützt, sollten Sie Ihre Recherche sorgfältig durchführen. Sie erhalten dann ein Gerät, das es unterstützt, oder Sie können ein neues oder gebrauchtes Gerät finden, das OpenWrt oder Tomato von Polarcloud unterstützt Sie haben die Gewissheit, das zu bekommen, was Sie brauchen.

Viel Glück. :)