Pourquoi certains routeurs WiFi bloquent-ils les paquets multicast allant du filaire au sans fil?

J'ai travaillé avec des dizaines de routeurs Wi-Fi grand public, et ils ont été très aléatoires, même si cela semble s'améliorer.

Exemple de problème:

1. Un périphérique qui peut être découvert avec mDNS est connecté au routeur avec un câble.
2. Un autre appareil connecté au routeur sur le WiFi tente de découvrir l'appareil à l'étape 1.
3. Les paquets de l'appareil sur le WiFi ne parviennent pas à l'appareil filaire, ou s'ils le font, les paquets envoyés à partir de l'appareil filaire ne parviennent pas à l'appareil sans fil.

De nombreux routeurs ont des paramètres permettant que cela fonctionne.

Voir http://community.linksys.com/t5/Wireless-Routers/WRT120N-WLAN-Issues/td-p/400073 et http://forums.verizon.com/t5/FiOS-Internet/Communication-between-wired -et-réseau-sans-fil-sur-actiontec / td-p / 461359 pour des exemples.

Y a-t-il une liste d'incompatibilité avec cela? Quelle est la cause? Juste un bug dans le routeur?

Cela est généralement dû à des bogues dans les routeurs de passerelle domestique Wi-Fi (AP), ou parfois dans les chipsets / pilotes / logiciels clients sans fil.

Sur le Wi-Fi, l'envoi de multidiffusions de l'AP aux clients sans fil (ceci est connu dans la norme sous le nom de "From the Distribution System" ou "FromDS") est délicat, donc il y a beaucoup de façons dont il peut échouer, et il est facile de introduire des bugs.

1. Même si le support radio n'est pas suffisamment fiable pour que les monodiffusions 802.11 doivent avoir des accusés de réception au niveau de la liaison (ACK) et être retransmises plusieurs fois s'il n'y a pas d'ACK, les multidiffusions FromDS ne sont jamais ACKées car elles devraient être ACKÉES par tous les clients sans fil de l'AP, qui pourrait être tout à fait une "tempête ACK". Par conséquent, les multidiffusions FromDS doivent être envoyées à un faible débit de données; en utilisant un schéma de modulation plus simple, plus lent, facile à décoder, même à faible rapport signal / bruit, qui peut, espérons-le, être reçu de manière fiable par tous les clients de l'AP. Certains points d'accès permettent à l'administrateur de définir le taux de multidiffusion, et certains administrateurs le fixent involontairement trop haut pour que certains de leurs clients reçoivent de manière fiable, interrompant la livraison de multidiffusion à ces clients.
2. Lorsque le cryptage WPA (TKIP) ou WPA2 (AES-CCMP) est utilisé, les multidiffusions FromDS doivent être cryptées avec une clé de cryptage distincte connue de tous les clients (c'est ce qu'on appelle la clé de groupe).
3. Lorsqu'un client quitte le réseau, ou toutes les heures environ, juste pour faire bonne mesure, la clé de groupe doit être modifiée de sorte que le client qui a quitté n'a plus accès pour déchiffrer les multidiffusions. Ce processus de "rotation de clé de groupe" a parfois des problèmes. Si un client n'accuse pas réception de la nouvelle clé de groupe, l'AP est censé désauthentifier ce client, mais s'il ne le fait pas en raison d'un bogue, un client peut avoir la mauvaise clé de groupe et donc être «sourd» "aux multidiffusions sans s'en rendre compte.
4. Lorsque le "mode mixte" WPA2 est activé (c'est-à-dire lorsque WPA et WPA2 sont activés en même temps), les multidiffusions FromDS doivent généralement être codées avec le chiffrement TKIP, afin que tous les clients soient garantis de savoir comment le décoder. .
5. Les multidiffusions FromDS doivent être mises en file d'attente par l'AP et transmises uniquement aux moments où tous les clients qui se soucient des multidiffusions doivent avoir leurs récepteurs sous tension. L'intervalle de temps entre les périodes de "diffusion sécurisée des multidiffusions FromDS" est appelé "intervalle DTIM". Si l'AP ou les clients bousillent leur gestion d'intervalle DTIM, cela pourrait empêcher les clients de recevoir des multidiffusions de manière fiable.
6. Certains points d'accès ont des fonctionnalités pour empêcher les clients sans fil de pouvoir communiquer directement entre eux, pour peut-être empêcher vos invités sans fil de pirater vos autres invités sans fil. Ces fonctionnalités bloquent généralement les multidiffusions des périphériques WLAN vers d'autres périphériques WLAN, et pourraient bien être mises en œuvre d'une manière naïve qui bloque même les multidiffusions du LAN au WLAN.

Ce qui est fou, c'est que les multidiffusions "ToDS" se font exactement comme les monodiffusions ToDS, et donc elles se cassent rarement. Et comme les multidiffusions ToDS (pas les multidiffusions FromDS) sont tout ce qui est nécessaire lorsqu'un client sans fil obtient un bail DHCP et des ARP pour trouver sa passerelle par défaut, la plupart des clients peuvent se connecter et surfer sur le Web, consulter leurs e-mails, etc. même lorsque FromDS les multidiffusions sont interrompues. Donc, beaucoup de gens ne réalisent pas qu'ils ont des problèmes de multidiffusion sur leur réseau avant d'essayer de faire des choses comme mDNS (alias IETF ZeroConf, Apple Bonjour, Avahi, etc.).

Quelques autres choses à noter concernant les transmissions multicast filaires à sans fil:

1. La plupart des multidiffusions LAN, telles que mDNS, sont effectuées à l'aide de plages d'adresses de multidiffusion spéciales qui ne sont pas censées être acheminées entre les routeurs. Étant donné que les passerelles domestiques compatibles Wi-Fi avec NAT activé sont considérées comme des routeurs, mDNS n'est pas censé passer du WAN au [W] LAN. Mais cela DEVRAIT fonctionner du LAN au WLAN.
2. Parce que les multidiffusions sur Wi-Fi doivent être envoyées à un faible débit, elles prennent beaucoup de temps d'antenne. Ils sont donc "chers" et vous ne voulez pas en avoir trop. C'est le contraire de la façon dont les choses fonctionnent sur Ethernet câblé, où les multidiffusions sont "moins coûteuses" que l'envoi de monodiffusions distinctes à chaque machine "en accordant un flux vidéo de multidiffusion" par exemple. Pour cette raison, de nombreux points d'accès Wi-Fi effectuent un "IGMP Snooping" pour surveiller les machines qui envoient des requêtes IGMP (Internet Group Management Protocol), exprimant leur désir de syntoniser un flux de multidiffusion donné. Les points d'accès Wi-Fi qui effectuent IGMP Snooping ne transfèrent pas automatiquement certaines classes de multidiffusions sur le réseau sans fil à moins qu'ils ne voient un client sans fil essayer de s'abonner à ce flux via IGMP. Les documents qui décrivent comment faire IGMP Snooping correctement indiquent clairement que certaines classes de multidiffusions à faible bande passante (mDNS fait partie de cette catégorie) sont censées toujours être transmises même si personne ne les a explicitement demandées via IGMP. Cependant, je ne serais pas surpris s'il existe des implémentations IGMP Snooping qui ne transfèrent absolument aucun type de multidiffusion jusqu'à ce qu'il voit une demande IGMP pour cela.

tl; dr: Bugs. Beaucoup de possibilités de bugs. Et parfois des fonctionnalités mal conçues et des erreurs de configuration. Votre meilleure défense consiste à acheter des points d'accès de haute qualité auprès d'entreprises soucieuses de garantir le bon fonctionnement des multidiffusions. Étant donné qu'Apple aime tant Bonjour (mDNS), les points d'accès d'Apple sont probablement les plus constamment excellents pour transmettre des multidiffusions de manière fiable, et les appareils clients Wi-Fi d'Apple sont probablement les plus constamment excellents pour recevoir des multidiffusions de manière fiable.

@Spiff a fait des remarques impressionnantes dans sa réponse et je ne le répéterai pas ici. Mais il existe d'autres réponses et alternatives pour contourner ce problème.

Réponse courte? Je ne pense pas qu'ils "bloquent" toujours autant qu'ils "ne le font pas pour commencer" en raison de la paresse des ingénieurs qui crée un appareil particulier. Certains ne l'ont pas comme une priorité élevée, et certains n'ont tout simplement pas le temps de le faire fonctionner.

Ce n'est pas une priorité sur la liste par rapport à toutes les nouvelles "fonctionnalités" que le marketing utilise pour vendre ces appareils grand public et c'est une fonctionnalité que la plupart des gens non avertis n'ont aucune idée, donc dans la liste des priorités, cela va jusqu'au moment où à moins qu'un grand nombre de propriétaires ne s'en plaignent, il est exclu des mises à jour de révision.

Si vous voulez un appareil qui le prend en charge, faites preuve de diligence dans vos recherches et vous obtiendrez un appareil qui le prend en charge, ou si vous pouvez trouver un appareil nouveau ou d'occasion qui prend en charge quelque chose comme OpenWrt ou Tomato de Polarcloud, vous pouvez être assuré d'obtenir ce dont vous avez besoin.

Bonne chance. :)