O multicast / RTSP da câmera IP está em conflito com os dispositivos sem fio?

Question

Aqui no nosso negócio, temos um Netgear R7000 executando o DD-WRT. Tenho vindo a adicionar lentamente câmeras IP que eu uso usando o software Blue Iris.

A última câmera que comprei (que NÃO é uma câmera sem fio), quando eu a conecto à rede, começo a ter problemas de conexão muito ruins na rede Wi-Fi de 2,4 GHz. O 5GHz funciona bem, apenas o 2.4GHz de repente tem problemas para se conectar, como se fosse conflitante. Eu tentei brincar com as configurações da câmera, diferentes endereços IP, portas HTTP, etc, e descobri que é um conflito com multicast.

Quando a multidifusão é verificada, o Wi-Fi tem problemas, mas o meu vídeo é transmitido via Blue Iris. Quando desmarcado, o Wi-Fi funciona bem, mas o vídeo não passa por Blue Iris. O problema é que não há configurações na câmera para alterar a porta RTSP, que é configurada como 34567.

Alguém sabe algo que poderia corrigir esse problema? Tudo parece muito estranho para mim, mas talvez alguém tenha uma ideia?

    

Answer 1

O multicast (e broadcast, que 802.11 trata como um caso especial de multicast) é muito caro em redes Wi-Fi, porque os pacotes multicast não são Acked (porque seria uma tempestade Ack), então os pacotes têm que ser enviado a uma taxa de pacote de menor denominador comum que todos na rede podem receber de forma confiável, e isso significa que muitas vezes é a menor taxa de dados que a banda pode suportar, que para 2.4GHz é a antiga taxa de 1Mbps de 802.11-1997 mesmo 802.11b).

Dado que, combinado com as ineficiências naturais do Wi-Fi, significa que até 500 kbps de tráfego multicast podem utilizar todo o tempo de antena de uma rede Wi-Fi de 2.4GHz mal concebida.

Se o seu AP permitir que você defina a taxa de multicast que ele usa, configure-o para algo maior. De preferência, cerca de duas vezes a taxa de todo o tráfego multicast / broadcast na sua rede. Ou seja, a taxa de dados do seu multicast de vídeo, mais a taxa média de dados agregados de coisas como Bonjour, UPnP, NetBIOS Name Service, ARP, DHCP, etc. Honestamente, o multicast de vídeo provavelmente supera o tráfego de segundo plano.

Tenha em atenção que, se tiver alguns dispositivos que pretenda utilizar em localizações que estejam na extremidade do respetivo intervalo, onde apenas podem obter a taxa de dados de 1 Mbps de forma fiável, você acabará por torná-los pouco fiáveis nesses locais . O ARP é fundamental para uma LAN funcionando corretamente, e o ARP usa broadcasts.

Se você definir a taxa de multicast como algo diferente de 1, 2, 5,5 ou 11 Mbps, estará excluindo os clientes 802.11b de sua rede. Portanto, para permitir a seleção de outras taxas, alguns APs exigem que você desabilite explicitamente o modo de compatibilidade 802.11b (ou seja, defina-o como modo G / N, ou somente G, ou N-only).

Alguns bons APs têm uma opção para "IGMP Snooping", que você provavelmente deveria habilitar. É uma maneira de um AP evitar o encaminhamento de certos tipos de multicasts (especialmente fluxos de áudio ou vídeo) para a rede sem fio, se nenhum dispositivo na rede sem fio estiver tentando visualizar esses multicasts. Apenas certifique-se de não executar o seu software de observação de câmera em qualquer máquina que esteja usando wireless.

A propósito, algumas câmeras de vídeo em rede do tipo lame ainda estão no mercado e não podem fazer compressão moderna como o H.264 e, ao invés disso, apenas MPEG2, ou pior, Motion-JPEG (M-JPEG). Isso significa que eles usam muito mais largura de banda de rede do que precisam, independentemente do problema de difusão seletiva Wi-Fi. Certifique-se de ter configurado suas câmeras para transmitir em H.264, e se elas não suportarem, retorne-as para um modelo diferente que saiba como fazer a compressão de vídeo moderna.

    

Answer 2

Achei que postaria o que acabou corrigindo isso no meu cenário.

No DD-WRT em configuração / rede, eu ativei o snooping IGMP para a ponte 0. Eu tive que adicionar este comando de inicialização:

insmod ebtables insmod ebtable_filter insmod ebt_pkttype ebtables -A FORWARD -o "eth1" - multicast tipo -pkttype -j DROP ebtables -A OUTPUT -o "eth1" - multicast tipo -pkttype -j DROP

Depois de finalmente descobrir que foram necessárias essas duas etapas, as coisas parecem estar funcionando bem novamente.