envenenamento ARP "legal" por máquina que agrega 2 placas de rede nos trava

Question

Eu realmente não tenho certeza se esse título faz algum sentido, então peço desculpas por isso, mas coisas estranhas estão acontecendo, ameaças estão sendo feitas e precisamos resolver esse problema;

A situação:

Nosso dispositivo (uma câmera de rede) transmite vídeo através de uma rede para um gravador / servidor (usando Live555 / WIS Streamer). O vídeo é de pacotes UDP.

Em um site específico usando um servidor específico, de vez em quando (~ 24 horas) um thread do streamer Live555 trava durante o envio de vídeo. Outros tópicos continuam, e ainda temos conectividade com a câmera sobre IP - veja as páginas da web, PING, etc.

Suspeitamos : o servidor; tem 2 portas de rede e as agrega - tem dois endereços MAC, mas um endereço IP. Em wiresharking isso, vemos a câmera fluindo para uma porta (vamos chamá-lo de A), então pegamos um ARP da outra porta (vamos chamá-lo de B), nosso dispositivo para esguichar pacotes para o MAC A, esguicha um pacote pelo fio para o MAC B e, em seguida, parece parar em suas faixas.

Mais informações : O servidor parece corromper os pacotes ARP da porta "errada", possivelmente como resultado de uma configuração incorreta ou algo assim, mas esses pacotes ainda são lidos & de acordo com o nosso dispositivo, possivelmente como resultado de nosso driver ou rede do kernel estar configurada incorretamente ou de pular checksums para economizar ciclos de CPU.

Então essa situação confusa faz algumas perguntas:

1. Onde no código de rede do kernel eu deveria estar olhando para verificar a soma de verificação de pacotes ou habilitar a verificação? Nosso hardware é fixo, sendo um dispositivo embutido, portanto, um ajuste feito ao driver não é a pior ideia de sempre.
2. Alguém pode adivinhar o mecanismo de falha que faz com que um processo seja bloqueado quando está constantemente send() dados em uma porta e as tabelas ARP se deslocam abaixo dela?

Editado para adicionar : Nós agora suspeitamos que os ARPs não são realmente corruptos, apenas que o Wireshark não está identificando corretamente o pacote (ele acha que o pacote é longo o suficiente para que haja uma palavra do FSC, mas agora achamos que é apenas preenchimento zero. Isso realmente deixa apenas a parte 2 desta questão: o que podemos fazer para evitar que essa mudança na tabela ARP atropele um processo de transmissão?

Editar para adicionar mais: não quero que as pessoas pensem que estou ignorando perguntas sobre estados de porta ou estados de processo, o problema acontece muito raramente (média talvez uma vez por 24h) e apenas em uma instalação (remota) que não podemos acessar facilmente, estamos tentando replicá-la no laboratório para que possamos fazer diagnósticos mais detalhados, mas o watchdog do sistema é redefinido dentro de aproximadamente 3 minutos do problema. tempo que a notícia chega até nós já está reiniciado e começou a trabalhar OK.

Editar para adicionar informações do Wireshark : Eu não tenho certeza da melhor maneira de resumir as capturas wireshark aqui (muito difícil de carregar ~ 1Tb de pacotes capturados!), Mas vou tentar. Cam:X & Cam:Y são dois fluxos de vídeo RTSP transmitidos por duas instâncias idênticas do Live555 WIS Streamer de portas diferentes. O servidor 'A' e 'B' são os MACs das duas NICs no servidor.

A sequência de pacotes é assim:

UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
ARP Packet to Cam from Server 'B' "<my IP> is now on 'B'"
Intel ANS Probe broadcast from Server 'B', Sender ID '1' team ID 'B'
Intel ANS Probe broadcast from Server 'A', Sender ID '2' team ID 'B'
<silence> from Cam:X
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'

Não há outros pacotes no fluxo durante esse período. Os pacotes da Intel ANS nem sempre coincidem com os ARPs da placa de rede, mas eu pensei em incluí-los para completar.

O problema parece ser MUITO sensível ao tempo, vemos esses ARPs de "equipe" regularmente do servidor e apenas uma vez em uma lua azul eles nos causam um problema - como se houvesse um ponto específico no código de pilha da rede que é sensível à alteração da tabela ARP. Nem sempre é a mesma instância de fluxo que cai, e notavelmente a outra instância (assim como todo o outro tráfego de rede - HTTP, etc.) continua funcionando bem.

Parece que os NICs agrupados "não devem" o ARP assim como no meio da sessão, mas é claro que eles não estarão cientes de nenhuma sessão quando o tráfego é todo UDP.

    

Answer 1

Bem, se apenas para dar algum fim a este cliente reconfigurou sua placa de rede desonesta e tudo funcionou, então infelizmente para os curiosos que significa que ninguém vai pagar a ninguém para ver de perto o que poderia ter sido feito para corrigir esse caso.