Estão a acontecer coisas estranhas, estão a ser feitas ameaças e precisamos de resolver este 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 são pacotes UDP.
Em um site específico usando um servidor específico, de vez em quando (aproximadamente 24 horas) um thread do streamer Live555 trava durante o envio de vídeo. Outros threads continuam, e ainda temos conectividade com a câmera via IP - veja as páginas da web dela, faça PING, etc.
Nós suspeitamos: o servidor; possui 2 portas de rede e as agrega - possui dois MACs, mas um endereço IP. No wiresharking, vemos a câmera transmitindo para uma porta (vamos chamá-la de A), então obtemos um ARP da outra porta (vamos chamá-la de B), nosso dispositivo para de esguichar pacotes para o MAC A, esguicha um pacote pelo fio para MAC B e então parece parar.
Mais informações: O servidor parece corromper pacotes ARP da porta "errada", possivelmente como resultado de uma configuração incorreta ou algo assim, mas esses pacotes ainda são lidos e acionados por nosso dispositivo, possivelmente como resultado de nossa rede de driver ou kernel estar mal configurada ou pulando somas de verificação para economizar ciclos de CPU.
Portanto, esta situação complicada levanta algumas questões:
- Onde no código de rede do kernel devo verificar a soma de verificação do pacote ou ativar a verificação? Nosso hardware é fixo, sendo um dispositivo embarcado, então um ajuste feito no driver não é a pior ideia de todas.
- Alguém consegue adivinhar o mecanismo de falha que causa o travamento de um processo quando ele está constantemente
send()enviando dados em uma porta e as tabelas ARP mudam abaixo dela?
Editado para adicionar: Agora suspeitamos que os ARPs não estão realmente corrompidos, apenas que o Wireshark não está identificando corretamente o pacote (ele acha que o pacote é longo o suficiente para que deva haver uma palavra FSC, mas agora achamos que é apenas preenchimento de zero). Isso realmente deixa apenas a parte 2 desta questão: o que podemos fazer para evitar que essa mudança na tabela ARP derrube um processo de transmissão?
Edite para adicionar ainda 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 (em média, talvez uma vez a cada 24 horas) e apenas em uma instalação (remota) à qual não podemos acessar facilmente, estamos nos esforçando para replicá-lo no laboratório para que possamos fazer diagnósticos mais detalhados, mas o watchdog do sistema é reiniciado cerca de 3 minutos após a ocorrência do problema, então, quando a notícia chega até nós, ela já foi reiniciada e começou a funcionar bem.
Edite para adicionar informações do Wireshark: Não tenho certeza da melhor maneira de resumir as capturas do wireshark aqui (é muito difícil fazer upload de ~ 1 TB de pacotes capturados!), Mas vou tentar. Cam:X& Cam:Ysão dois fluxos de vídeo RTSP transmitidos por duas instâncias idênticas do Live555 WIS Streamer de portas diferentes. Os servidores '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 nesse horário ou próximo a ele. Os pacotes Intel ANS nem sempre coincidem com os ARPs da NIC, mas pensei em incluí-los para fins de integridade.
O problema parece ser MUITO sensível ao tempo, vemos esses ARPs de "equipe" regularmente no servidor e apenas uma vez na lua azul eles nos causam um problema - como se houvesse um ponto específico no código da pilha de rede que é sensível ao Alteração da tabela ARP. Nem sempre é a mesma instância de fluxo que cai e, principalmente, a outra instância (assim como todo o outro tráfego de rede - HTTP etc.) continua funcionando bem.
Parece que NICs em equipe "não deveriam" usar ARP como esse no meio da sessão, mas é claro que eles não estarão cientes de nenhuma sessão quando o tráfego for todo UDP.
Responder1
Bem, apenas para dar um poucofechopara isso, o cliente reconfigurou sua placa de rede duvidosa e tudo funcionou, então, infelizmente para os curiosos, isso significa que ninguém vai pagar ninguém para olhar muito de perto o que poderia ter sido feito para consertar esse caso.