Geralmente, isso ocorre devido a erros nos roteadores de gateway doméstico Wi-Fi (APs) ou às vezes nos chipsets / drivers / software do cliente sem fio.
No Wi-Fi, o envio de multicasts do ponto de acesso para os clientes sem fio (isso é conhecido no padrão como "Do sistema de distribuição" ou "FromDS") é complicado, por isso há muitas maneiras pelas quais isso pode falhar e é fácil introduzir erros.
- Mesmo que a mídia de rádio não seja confiável o suficiente, é necessário que os unicasts 802.11 tenham confirmações no nível do link (ACKs) e sejam retransmitidos várias vezes se não houver ACK, as multicasts do FromDS nunca são aceitas porque precisam ser aceitas por todos os clientes sem fio do AP, o que poderia ser uma "tempestade ACK". Então, em vez disso, as multicasts do FromDS precisam ser enviadas a uma baixa taxa de dados; usando um esquema de modulação mais simples, mais lento, fácil de decodificar e até com baixo sinal-ruído-rácios, que esperemos que possa ser recebido com segurança por todos os clientes do AP. Alguns APs permitem que o administrador defina a taxa de difusão seletiva, e alguns administradores involuntariamente a definem muito alto para que alguns de seus clientes recebam de maneira confiável, interrompendo a entrega de difusão seletiva para esses clientes.
- Quando a criptografia WPA (TKIP) ou WPA2 (AES-CCMP) está em uso, os multicasts do FromDS precisam ser criptografados com uma chave de criptografia separada que é conhecida por todos os clientes (isso é chamado de chave de grupo).
- Quando um cliente sai da rede, ou a cada hora ou mais, apenas por uma boa medida, a Chave de Grupo precisa ser alterada para que o cliente que saiu não tenha mais acesso para descriptografar os multicasts. Esse processo de "Rotação da chave de grupo" às vezes apresenta problemas. Se um cliente não confirmar o recebimento da nova chave de grupo, o PA deverá autenticar esse cliente, mas, se não conseguir fazer isso devido a um bug, o cliente poderá ter a chave de grupo incorreta e, portanto, ficar "surdo". "para multicasts sem perceber.
- Quando o "modo misto" do WPA2 é ativado (ou seja, quando o WPA e o WPA2 são ativados ao mesmo tempo), os multicasts do FromDS geralmente precisam ser codificados com a cifra TKIP, para que todos os clientes saibam como decodificá-lo. .
- Os multicasts do FromDS precisam ser enfileirados pelo ponto de acesso e transmitidos apenas quando é esperado que todos os clientes que se preocupam com os multicasts tenham seus receptores ligados. O tempo entre os períodos "seguro para transmitir multicasts do FromDS" é chamado de "intervalo DTIM". Se o ponto de acesso ou os clientes estragar sua manipulação de intervalo DTIM, isso poderá resultar em clientes incapazes de receber multicasts de maneira confiável.
- Alguns pontos de acesso têm recursos para impedir que os clientes sem fio possam conversar diretamente entre si, talvez para impedir que seus convidados sem fio invadam seus outros convidados sem fio. Esses recursos geralmente bloqueiam multicasts dos dispositivos WLAN para outros dispositivos WLAN e podem muito bem ser implementados de uma maneira ingênua que até bloqueia os multicasts da LAN para a WLAN.
O mais louco é que as multicasts do "ToDS" são feitas como os unicasts do ToDS e, portanto, raramente quebram. E como os multicasts do ToDS (não os multicasts do FromDS) são tudo o que é necessário quando um cliente sem fio recebe uma concessão DHCP e ARPs para encontrar seu gateway padrão, a maioria dos clientes consegue se conectar e navegar na web, verificar e-mails, etc. mesmo quando o FromDS multicasts estão quebrados. Assim, muitas pessoas não percebem que têm problemas de multicast em sua rede até tentarem fazer coisas como mDNS (também conhecido como IETF ZeroConf, Apple Bonjour, Avahi, etc.).
Algumas outras coisas a serem observadas, com relação às transmissões multicast sem fio:
- A maioria das multicasts da LAN, como o mDNS, é feita usando intervalos de endereços multicast especiais que não devem ser roteados pelos roteadores. Como os gateways domésticos compatíveis com Wi-Fi com NAT habilitado contam como roteadores, o mDNS não deve passar da WAN para a [W] LAN. Mas DEVE trabalhar da LAN para a WLAN.
- Como as multicasts no Wi-Fi precisam ser enviadas com uma baixa taxa de dados, elas levam muito tempo no ar. Portanto, eles são "caros" e você não deseja ter muitos deles. É o oposto de como as coisas funcionam na Ethernet com fio, onde multicasts são "menos caros" do que enviar unicasts separados para cada máquina "sintonizando em um fluxo de vídeo multicast", por exemplo. Por esse motivo, muitos pontos de acesso Wi-Fi farão o "IGMP Snooping" para observar quais máquinas estão enviando solicitações do Internet Group Management Protocol (IGMP), expressando seu desejo de sintonizar um determinado fluxo de difusão seletiva. Os pontos de acesso Wi-Fi que fazem o IGMP Snooping não encaminham automaticamente algumas classes de multicasts para a rede sem fio, a menos que eles vejam que um cliente sem fio tenta se inscrever nesse fluxo via IGMP. Os documentos que descrevem como executar o IGMP Snooping corretamente deixam claro que certas classes de multicasts de baixa largura de banda (mDNS se encaixam nessa categoria) devem sempre ser encaminhadas, mesmo que ninguém as solicite explicitamente via IGMP. No entanto, não ficaria surpreso se houver implementações quebradas de IGMP Snooping por aí que nunca encaminham nenhum tipo de multicast até que ele veja uma solicitação IGMP.
tl; dr: Erros. Muitas oportunidades para bugs. E recursos ocasionais mal projetados e erros de configuração. Sua melhor defesa é comprar APs de alta qualidade de empresas que se preocupam em garantir que os multicasts funcionem. Como a Apple ama tanto o Bonjour (mDNS), os pontos de acesso da Apple são provavelmente os mais consistentemente excelentes em transmitir multicasts de maneira confiável, e os dispositivos clientes Wi-Fi da Apple são provavelmente os mais consistentemente excelentes em receber multicasts de maneira confiável.