Pourquoi certains routeurs WiFi bloquent-ils les paquets multicast allant du mode câblé au mode sans fil?
J'ai travaillé avec des dizaines de routeurs WiFi grand public, et ils ont été très impressionnés, même si cela semble s'améliorer.
Exemple de problème:
- Un périphérique pouvant être découvert avec mDNS est connecté au routeur avec un câble.
- Un autre périphérique connecté au routeur via WiFi tente de le détecter à l'étape 1.
- Les paquets de l'appareil en WiFi ne parviennent pas au périphérique câblé, ou s'ils le font, les paquets envoyés à partir du périphérique câblé ne parviennent pas au périphérique sans fil.
De nombreux routeurs ont des paramètres permettant à cela de fonctionner.
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-and-wireless-network-on-actiontec/td-p/461359 pour des exemples.
Existe-t-il une liste d'incompatibilités avec cela? Quelle est la cause? Juste un bug dans le routeur?
Cela est généralement dû à des bugs dans les routeurs de passerelle domestique Wi-Fi, ou parfois dans les chipsets/pilotes/logiciels du client sans fil.
En mode Wi-Fi, l’envoi de multidiffusions de l’AP aux clients sans fil (connu sous le nom standard "Depuis le système de distribution" ou "FromDS") est délicat, de sorte qu’il peut échouer de nombreuses façons, et il est facile de introduire des bugs.
- Même si le support radio n'est pas suffisamment fiable, les monodiffusions 802.11 doivent posséder des accusés de réception de niveau liaison (ACK) et être retransmises plusieurs fois s'il n'y a pas d'accusé de réception, les multidiffusions FromDS ne sont jamais acquittées, car elles doivent être acquittées par tous les clients sans fil. de l'AP, qui pourrait être tout à fait une "tempête ACK". Au lieu de cela, les multidiffusions FromDS doivent être envoyées à un faible débit de données; 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 du point d'accès. Certains points d'accès permettent à l'administrateur de définir le taux de multidiffusion, tandis que certains administrateurs le fixent involontairement à un niveau trop élevé pour que certains de leurs clients puissent recevoir de manière fiable, interrompant ainsi la transmission multidiffusion à ces clients.
- 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 (appelée clé de groupe). .
- Lorsqu'un client quitte le réseau, ou toutes les heures environ, pour que cela soit une bonne mesure, la clé de groupe doit être modifiée afin que le client qui le quitte n'ait plus accès au déchiffrement des 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, le PA est supposé désauthentifier ce client, mais s'il échoue à cause d'un bogue, un client pourrait avoir la mauvaise clé de groupe et ainsi être "sourd" "faire des multidiffusions sans s'en rendre compte.
- Lorsque le "mode mixte" WPA2 est activé (c'est-à-dire lorsque WPA et WPA2 sont activés simultanément), les multidiffusions FromDS doivent généralement être codées avec le chiffrement TKIP, de sorte que tous les clients soient garantis. savoir le décoder.
- Les multidiffusions FromDS doivent être mises en file d'attente par le point d'accès et transmises uniquement aux moments où tous les clients concernés par la multidiffusion doivent pouvoir allumer leurs récepteurs. Le temps entre les périodes de "multidiffusion sûre à partir de FromDS" est appelé "intervalle DTIM". Si le PA ou les clients bousillent la gestion de leurs intervalles DTIM, les clients ne pourront pas recevoir les multidiffusions de manière fiable.
- Certains points d'accès ont des fonctionnalités qui empêchent les clients sans fil de se parler directement, voire d'empêcher vos invités sans fil de pirater vos autres invités sans fil. Ces fonctionnalités bloquent généralement les multidiffusions de périphériques WLAN vers d’autres périphériques WLAN, et pourraient bien être implémentées d’une manière naïve qui bloque même les multidiffusions de réseau local à réseau local sans fil.
Ce qui est fou, c'est que les multicasts "ToDS" se font comme des unicasts, et ainsi, ils se cassent rarement. Et comme les multidiffusions ToDS (et non les multidiffusions FromDS) sont tout ce dont vous avez besoin lorsqu'un client sans fil obtient un bail DHCP et que les ARP recherchent 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. Ainsi, beaucoup de personnes ne réalisent pas qu’elles ont des problèmes de multidiffusion sur leur réseau avant d’essayer de faire des choses comme mDNS (a.k.a. IETF ZeroConf, Apple Bonjour, Avahi, etc.).
Quelques autres points à noter, concernant les transmissions multicast câblées ou sans fil:
- La plupart des multidiffusions LAN, telles que mDNS, utilisent des plages d’adresses de multidiffusion spéciales qui ne sont pas destinées à être routées entre routeurs. Étant donné que les passerelles domestiques compatibles Wi-Fi avec NAT activé sont considérées comme des routeurs, mDNS n'est pas conçu pour passer de WAN à [W] LAN. Mais cela DEVRAIT fonctionner de LAN à WLAN.
- Étant donné que les multidiffusions sur le Wi-Fi doivent être envoyées à un faible débit de données, elles prennent beaucoup de temps d’antenne. Elles sont donc "chères" et vous ne voulez pas en avoir trop. C'est l'inverse de la façon dont les choses fonctionnent sur Ethernet câblé, où les multidiffusions sont "moins onéreuses" que d'envoyer des monodiffusions séparées à chaque machine "s'accordant sur un flux vidéo multidiffusion" par exemple. De ce fait, de nombreux points d’accès Wi-Fi effectuent une "surveillance IGMP" pour surveiller les machines qui envoient des requêtes IGMP (Internet Group Management Protocol), exprimant ainsi leur volonté de syntoniser un flux de multidiffusion donné. Les points d'accès Wi-Fi IGMP Snooping ne transmettent pas automatiquement certaines classes de multidiffusions sur le réseau sans fil à moins qu'un client sans fil ne tente de s'abonner à ce flux via IGMP. Les documents décrivant comment effectuer correctement la surveillance IGMP indiquent clairement que certaines classes de multidiffusions à faible bande passante (mDNS appartient à 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 cassées qui ne transmettent absolument aucun type de multidiffusion jusqu'à ce qu'une requête IGMP le détecte.
tl; dr: Bugs. Beaucoup de possibilités pour les bugs. Et occasionnellement des fonctionnalités mal conçues et des erreurs de configuration. Votre meilleure défense consiste à acheter des points d'accès de grande qualité auprès d'entreprises qui veillent au bon fonctionnement de la multidiffusion. Comme Apple aime tellement Bonjour (mDNS), les AP d’Apple sont probablement les systèmes les plus fiables pour transmettre des multidiffusions de manière fiable, et les périphériques clients Wi-Fi d’Apple sont sans doute les meilleurs pour recevoir des multidiffusions de manière fiable.
@Spiff a fait quelques remarques impressionnantes dans sa réponse et je ne le répéterai pas ici. Mais il existe d'autres solutions et solutions pour contourner ce problème.
Réponse courte? Je ne pense pas qu'ils "bloquent" toujours autant qu'ils "ne le font pas ou ne commencent pas par" en raison de la paresse d'un ingénieur qui crée un dispositif particulier. Certains n’ont pas la priorité absolue et d’autres n’ont tout simplement pas le temps de la faire fonctionner.
Ce n’est pas une priorité sur la liste des priorités comparée à toutes les nouvelles "fonctionnalités" utilisées par le marketing pour vendre ces dispositifs grand public. C’est une fonctionnalité que la plupart des non-initiés aux technologies n’ont aucune idée; À moins que de nombreux propriétaires s'en plaignent, les mises à jour de révision ne sont pas prises en compte.
Si vous voulez un appareil qui le supporte, faites preuve de diligence raisonnable dans votre recherche et vous obtiendrez un appareil qui le supportera, ou si vous pouvez trouver un appareil neuf ou usagé qui prend en charge quelque chose comme OpenWrt ou Tomate de Polarcloud, vous pouvez être assuré d'obtenir ce dont vous avez besoin.
Bonne chance. :)