¿Por qué algunos enrutadores WiFi bloquean los paquetes de multidifusión que van de cable a inalámbricos?

He trabajado con docenas de enrutadores WiFi de grado de consumo, y han sido realmente acertados con esto, aunque parece estar mejorando.

Ejemplo de problema:

1. Un dispositivo que se puede descubrir con mDNS está conectado al enrutador con un cable.
2. Otro dispositivo conectado al enrutador en WiFi intenta descubrir el dispositivo en el paso 1.
3. Los paquetes del dispositivo en WiFi no llegan al dispositivo con cable, o si lo hacen, los paquetes enviados desde el dispositivo con cable no llegan al dispositivo inalámbrico.

Muchos enrutadores tienen configuraciones que permiten que esto funcione.

Consulte http://community.linksys.com/t5/Wireless-Routers/WRT120N-WLAN-Issues/td-p/400073 y http://forums.verizon.com/t5/FiOS-Internet/Communication-between-wired -and-wireless-network-on-actiontec / td-p / 461359 para ver ejemplos.

¿Hay alguna lista de incompatibilidad con esto? ¿Cual es la causa? ¿Solo un error en el enrutador?

Por lo general, se debe a errores en los enrutadores de puerta de enlace (AP) del hogar con Wi-Fi o, a veces, en los conjuntos de chips / controladores / software del cliente inalámbrico.

En Wi-Fi, el envío de multidifusiones desde el AP a los clientes inalámbricos (esto se conoce en el estándar como "Desde el sistema de distribución" o "FromDS") es complicado, por lo que hay muchas formas en que puede fallar, y es fácil Introducir errores.

1. Aunque el medio de radio no es lo suficientemente confiable como para que se requiera unidifusión 802.11 para tener acuses de recibo de nivel de enlace (ACK) y se retransmitan varias veces si no hay ACK, las multidifusiones FromDS nunca se ACK porque tendrían que ser ACK por todos los clientes inalámbricos de la AP, que podría ser una "tormenta ACK". En cambio, las multidifusiones FromDS deben enviarse a una velocidad de datos baja; utilizando un esquema de modulación más simple, más lento, fácil de decodificar, incluso con señales bajas de ruido, que esperamos que todos los clientes del AP puedan recibir de manera confiable. Algunos puntos de acceso permiten que el administrador establezca la tasa de multidifusión, y algunos administradores, inconscientemente, la establecen demasiado alta para que algunos de sus clientes reciban de manera confiable, interrumpiendo la entrega de multidifusión a esos clientes.
2. Cuando se utiliza el cifrado WPA (TKIP) o WPA2 (AES-CCMP), las multidifusiones FromDS deben cifrarse con una clave de cifrado separada que todos los clientes conocen (esto se denomina clave de grupo).
3. Cuando un cliente abandona la red, o cada hora más o menos, solo por si acaso, la clave de grupo debe cambiarse para que el cliente que dejó ya no tenga acceso para descifrar las multidifusiones. Este proceso de "Rotación de clave de grupo" a veces tiene problemas. Si un cliente no acusa recibo de la nueva clave de grupo, se supone que el AP debe des autenticar a ese cliente, pero si no lo hace debido a un error, un cliente podría tener la clave de grupo incorrecta y, por lo tanto, estar "sordo". "a multidifusión sin darse cuenta.
4. Cuando el "modo mixto" WPA2 está habilitado (es decir, cuando tanto WPA como WPA2 están habilitados al mismo tiempo), las multidifusiones FromDS generalmente deben codificarse con el cifrado TKIP, de modo que se garantice que todos los clientes sepan cómo decodificarlo. .
5. El AP debe poner en cola las multidifusiones de FromDS y solo transmitirlas cuando se espera que todos los clientes que se preocupan por las multidifusiones tengan sus receptores encendidos. El tiempo entre los períodos de "transmisión segura de multidifusión FromDS" se denomina "intervalo DTIM". Si el AP o los clientes arruinan su manejo del intervalo DTIM, podría resultar en que los clientes no puedan recibir multidifusiones de manera confiable.
6. Algunos puntos de acceso tienen características para evitar que los clientes inalámbricos puedan comunicarse directamente entre ellos, tal vez para evitar que sus invitados inalámbricos pirateen a sus otros invitados inalámbricos. Estas características generalmente bloquean las multidifusiones de dispositivos WLAN a otros dispositivos WLAN, y podrían implementarse de una manera ingenua que incluso bloquea las multidifusiones de LAN a WLAN.

Lo loco es que las multidifusiones "ToDS" se realizan al igual que las unidifusiones ToDS, por lo que rara vez se rompen. Y dado que las multidifusiones ToDS (no las multidifusiones FromDS) son todo lo que se necesita cuando un cliente inalámbrico obtiene una concesión DHCP y ARP para encontrar su puerta de enlace predeterminada, la mayoría de los clientes pueden conectarse y navegar por la web, consultar el correo electrónico, etc., incluso cuando FromDS Las multidifusiones están rotas. Por lo tanto, muchas personas no se dan cuenta de que tienen problemas de multidifusión en su red hasta que intentan hacer cosas como mDNS (también conocido como IETF ZeroConf, Apple Bonjour, Avahi, etc.).

Un par de otras cosas a tener en cuenta, con respecto a las transmisiones de multidifusión cableadas a inalámbricas:

1. La mayoría de las multidifusiones LAN, como mDNS, se realizan utilizando rangos de direcciones de multidifusión especiales que no están destinados a enrutarse a través de enrutadores. Dado que las puertas de enlace domésticas con capacidad Wi-Fi con NAT habilitada cuentan como enrutadores, mDNS no debe cruzar de WAN a [W] LAN. Pero DEBE funcionar de LAN a WLAN.
2. Debido a que las multidifusiones en Wi-Fi tienen que enviarse a una velocidad de datos baja, requieren mucho tiempo de aire. Por lo tanto, son "caros" y no querrás tener demasiados. Eso es lo opuesto a cómo funcionan las cosas en Ethernet cableada, donde las multidifusiones son "menos costosas" que enviar unicastias separadas a cada máquina "sintonizando una transmisión de video de multidifusión", por ejemplo. Debido a esto, muchos puntos de acceso Wi-Fi harán "IGMP Snooping" para ver qué máquinas están enviando solicitudes de Protocolo de administración de grupos de Internet (IGMP), expresando su deseo de sintonizar un flujo de multidifusión determinado. Los puntos de acceso de Wi-Fi que hacen IGMP Snooping no reenviarán automáticamente algunas clases de multidifusión a la red inalámbrica a menos que vean que un cliente inalámbrico intenta suscribirse a esa transmisión a través de IGMP. Los documentos que describen cómo hacer IGMP Snooping dejan en claro que ciertas clases de multidifusiones de bajo ancho de banda (mDNS encaja en esta categoría) siempre deben reenviarse incluso si nadie las ha pedido explícitamente a través de IGMP. Sin embargo, no me sorprendería si hay implementaciones de IGMP Snooping rotas que nunca envían ningún tipo de multidifusión hasta que ve una solicitud IGMP para ello.

tl; dr: Errores. Muchas oportunidades para errores. Y ocasionales características mal diseñadas y errores de configuración. Su mejor defensa es comprar AP de alta calidad de compañías que se preocupan por asegurarse de que funcionen las multidifusiones. Dado que Apple ama tanto a Bonjour (mDNS), los AP de Apple son probablemente los más consistentemente excelentes para pasar multidifusiones de manera confiable, y los dispositivos cliente de Wi-Fi de Apple son probablemente los más consistentemente excelentes para recibir multidifusiones de manera confiable.

@Spiff hizo algunos puntos increíbles en su respuesta y no lo reiteraré aquí. Pero hay algunas otras respuestas y alternativas para solucionar este problema.

¿Respuesta corta? No creo que siempre "bloqueen" tanto como simplemente "no lo hacen de otra manera" debido a la pereza de los ingenieros que crean cualquier dispositivo en particular. Algunos no lo tienen como una alta prioridad, y algunos simplemente no tienen el tiempo para hacerlo funcionar.

No ocupa un lugar destacado en la lista de prioridades en comparación con todas las nuevas "características" que el marketing está utilizando para vender estos dispositivos de grado de consumo y es una característica que la mayoría de las personas no expertas en tecnología no tienen idea, por lo que la lista de prioridades va hasta el punto que a menos que un gran grupo de propietarios se queje de ello, queda excluido de cualquier actualización de revisión.

Si desea un dispositivo que lo admita, haga la diligencia debida en su investigación y obtendrá un dispositivo que lo admita, o si puede encontrar un dispositivo nuevo o usado que admita algo como OpenWrt o Tomato de Polarcloud, puede ser seguro de obtener lo que necesita.

Buena suerte. :)