Há muitos APs 802.11 e cartões de cliente baratos com suporte multicast * quebrado, especialmente quando a criptografia está ativada e especialmente especialmente quando o modo misto WPA2 (AES-CCMP simultaneamente com TKIP) ou O 802.11i TSN (AES-CCMP e / ou TKIP simultaneamente com WEP) está ativado.
* Nota: No 802.11, a transmissão é um subconjunto do multicast: é um multicast que vai para todos . Então, quando eu disser "multicast", pense em "multicast / broadcast".
No 802.11, o multicast é mais complicado no AP - > a direção do cliente, porque tem que ser enviada a uma taxa multicast de menor denominador comum, não é confirmada ou reenviada na camada 802.11, e se você tiver criptografia WPA ou WPA2 ativada, ela deve ser enviada criptografada com uma taxa diferente. key (a chave do grupo), e se você tiver o WPA2 Mixed Mode ou o 802.11i TSN ativado, ele deve ser enviado não apenas com uma chave diferente, mas com uma cifra diferente (uma codificação de menor denominador comum; TKIP no caso WPA2 Mixed Mode e WEP no caso do TSN).
Uma maneira rápida de ver se é apenas um problema multicast é adicionar manualmente entradas ARP estáticas em cada máquina, para que eles saibam os mapeamentos de "endereço IP - > endereço MAC sem fio" um do outro e, em seguida, ver se você consegue executar o ping . O ARP usa broadcasts, portanto, os multicasts quebrados em uma rede 802.11 quebram a capacidade de um cliente sem fio receber transmissões ARP quando outros clientes estão tentando procurar o endereço MAC do cliente sem fio. Sem o mapeamento ARP, o quadro de ping não pode ser endereçado na camada 802.11, portanto, não pode ser transmitido.
Se os mapeamentos ARP estáticos corrigirem isso, tente desativar temporariamente toda a criptografia sem fio, exclua os mapeamentos ARP estáticos e tente o teste novamente. Se o ARP funciona dessa vez, é um sinal de que o multicast não está completamente quebrado em seu equipamento 802.11, ele está quebrado quando a criptografia está ativada.
Por enquanto, alguns podem estar perguntando: "Mas se as transmissões forem interrompidas, por que o DHCP funcionou? O DHCP usa transmissões!", e você está certo que o DHCP usa transmissões, mas no DHCP apenas as mensagens de o cliente para o servidor é transmitido. Na outra direção, eles são geralmente unicast. E é somente na direção do para o cliente que os multicasts são complicados no 802.11.
Verifique com seu fornecedor de cartão de cliente e AP quanto a atualizações de firmware e driver. Sempre compre equipamentos 802.11 com certificação Wi-Fi, porque o teste de certificação Wi-Fi é testado especificamente para garantir que a multidifusão funcione mesmo quando a criptografia está ativada. Por favor também "nomeie e envergonhe" os fornecedores do AP e do (s) cartão (s) do cliente em questão.
Quando o multicast é quebrado entre um AP e um cliente, não consigo pensar em uma maneira fácil de saber se a falha é com o AP ou o cliente, além do processo de eliminação, vendo se outras marcas de os clientes sem fio têm o mesmo problema naquele ponto de acesso e vendo se esse cliente sem fio tem o mesmo problema em outras marcas de pontos de acesso.
A maneira mais avançada de colocar a culpa em uma extremidade ou outra é usar outra máquina que não faz parte do teste, mas possui uma placa 802.11, para fazer um rastreamento de pacote no modo 802.11, começando antes do cliente sem fio associados. Alguém bem versado em handshake de 802.11 e WPA [2] e afins provavelmente pode analisá-lo e descobrir onde apontar os dedos.
Eu faço a maior parte do meu trabalho de rede em Macs, por isso não posso orientá-lo em obter rastreios de pacote no modo monitor 802.11 em outras plataformas, mas caso você tenha uma caixa do Snow Leopard (Mac OS X v10.6) você pode fazer:
sudo /usr/libexec/airportd en1 sniff 1
[...run your test...]
^C
... para fazer uma captura de modo de monitor 802.11, via en1, que normalmente é a placa AirPort integrada na maioria dos Macs, no canal 1. Modifique se a sua placa AirPort não é en1 ou se seu AP não está no canal 1.
Ou você pode fazer:
/System/Library/PrivateFrameworks/Apple80211.framework/Resources/airport -z -c1
sudo tcpdump -I -y IEEE802_11_radio -s0 -w monitorModeTrace.pcap
[...run your test...]
^C
(O argumento -c1 para a ferramenta airport coloca a interface no canal 1; modifique isso para o canal em que seu AP está ligado.)
Ou você pode executar o Wireshark, tshark, etc., mas no Mac você ainda precisará usar o comando airport para definir o canal e forçar uma dissociação.