O que poderia fazer com que um ponto de acesso 802.11n com atividade multicast falhasse quando um cliente sem fio fica fora do alcance?

Eu tenho um Raspberry Pi (rodando Raspbian) e um adaptador USB sem fio LB-LINK servindo como um ponto de acesso 802.11n com WPA2, rodando com hostapd e isc-dhcp-server. No Pi, eu tenho um script python que envia pacotes multicast de cerca de 50 bytes a uma taxa de 25Hz. Percebemos que quando um cliente sem fio fica fora do alcance (e às vezes quando volta ao intervalo) do AP, o AP começa a se comportar de maneira estranha. Especificamente, o comando socket.sendto () nos blocos de script python e os clientes sem fio desconectados não podem entrar na rede. Nos tablets Android, a rede aparece com 1 barra de intensidade de sinal, mesmo que estejam bem próximos da antena. Os clientes já conectados ao AP parecem permanecer conectados (a captura do Wireshark de um cliente que já estava conectado mostra que ele continua trocando pacotes com o roteador) e mostra uma barra cheia de intensidade do sinal. Observe que o cliente sem fio que sai do intervalo não precisa fazer parte do grupo de multicast (pelo menos, eu nunca defini explicitamente que seja, e não estamos enviando para o grupo de todos os hosts). O canal sem fio que estamos usando não é usado por outros pontos de acesso próximos. O hostapd não reporta nenhuma anormalidade, e pará-lo e iniciá-lo não corrige o problema. Nós não vimos isso com o tráfego UDP regular sendo enviado na mesma taxa.

Alguém sabe por que tirar um cliente sem fio fora do alcance do ponto de acesso conectado pode fazer com que o ponto de acesso "caia" se houver dados multicast sendo enviados pela rede? Infelizmente, não tenho muitos recursos para continuar com essa questão, por isso estou apenas pedindo para ver se o problema parece familiar a alguém e se eles foram capazes de resolvê-lo.

EDITAR: Acabei de reproduzir isso em hardware completamente diferente. Um NETGEAR WNR2000 com os pacotes multicast provenientes de um aplicativo Visual C ++ em execução em um dispositivo WinCE conectado via ethernet (ou seja, completamente diferente da configuração usada acima). Parece ser mais raro com essa configuração, mas eu definitivamente fiz isso acontecer.

Pode ser que, à medida que o dispositivo atinja a borda do intervalo, o adaptador usb comece a solicitar mais energia do que o Pi pode fornecer e, assim, levar à instabilidade. Isso faria sentido, na medida em que afetasse apenas o tráfego TCP, que requer uma resposta, enquanto o tráfego UDP nunca poderia atingir o alvo e simplesmente ser descartado, sem causar nenhum problema.

Eu não estou entendendo como você tem "multicast TCP"

O que causaria isso? Um bug no modo AP suporta o driver do chipset Wi-Fi do seu AP. Bem, o driver, ou o firmware do chipset, ou potencialmente no hardware do próprio chipset.

Se você tiver acesso às fontes do dito driver para tentar depurá-lo, eu começaria olhando como ele lida com a entrega multicast quando os clientes invocam o modo de economia de energia 802.11.

Se você quer apenas contorná-lo, comece experimentando um adaptador USB Wi-Fi de marca de alta qualidade, com um chipset de um fornecedor de primeira linha, como Broadcom ou QCA (Qualcomm Atheros).