Están sucediendo cosas extrañas, se están lanzando amenazas y debemos solucionar este problema;
La situación:
Nuestro dispositivo (una cámara de red) transmite vídeo a través de una red a una grabadora/servidor (usando Live555/WIS Streamer). El vídeo son paquetes UDP.
En un sitio en particular que utiliza un servidor en particular, de vez en cuando (~24 horas) un hilo del transmisor Live555 se bloquea mientras envía video. Otros hilos continúan y todavía tenemos conectividad a la cámara a través de IP: ver páginas web, hacer PING, etc.
Sospechamos: el servidor; tiene 2 puertos de red y los agrega: tiene dos MAC pero una dirección IP. Al hacer esto con el cable, vemos que la cámara transmite a un puerto (llamémoslo A), luego obtenemos un ARP del otro puerto (llamémoslo B), nuestro dispositivo deja de enviar paquetes a MAC A, envía un paquete por el cable. a MAC B y luego parece detenerse en seco.
Informacion adicional: El servidor parece corromper los paquetes ARP del puerto "incorrecto", posiblemente como resultado de una mala configuración o algo así, pero nuestro dispositivo aún lee y actúa sobre esos paquetes, posiblemente como resultado de que nuestro controlador o la red del kernel estén mal configurados o omitiendo sumas de comprobación para ahorrar ciclos de CPU.
Entonces, esta complicada situación plantea algunas preguntas:
- ¿En qué parte del código de red del kernel debería buscar para verificar la suma de verificación del paquete o habilitar la verificación? Nuestro hardware es fijo, ya que es un dispositivo integrado, por lo que modificar el controlador no es la peor idea.
- ¿Alguien puede adivinar el mecanismo de falla que causa que un proceso se bloquee cuando constantemente
send()envía datos a un puerto y las tablas ARP se mueven debajo de él?
Editado para agregar: Ahora sospechamos que los ARP no están realmente corruptos, solo que Wireshark no identifica correctamente el paquete (cree que el paquete es lo suficientemente largo como para que haya una palabra FSC, pero ahora creemos que es solo relleno de ceros). Eso realmente solo nos deja la parte 2 de esta pregunta: ¿qué podemos hacer para evitar que este cambio en la tabla ARP derribe un proceso de transmisión?
Edite para agregar más:No quiero que la gente piense que estoy ignorando preguntas sobre los estados de los puertos o los estados de los procesos, el problema ocurre muy raramente (en promedio, tal vez una vez cada 24 horas) y solo en una instalación (remota) a la que no podemos acceder fácilmente. Estamos intentando replicarlo en el laboratorio para poder realizar diagnósticos más detallados, pero el sistema de vigilancia del sistema se restablece aproximadamente 3 minutos después de que ocurre el problema, por lo que cuando nos llega la noticia, ya se ha reiniciado y ha comenzado a funcionar correctamente.
Editar para agregar información de Wireshark: No estoy seguro de cuál es la mejor manera de resumir las capturas de Wirehark aquí (¡es muy difícil cargar ~1 TB de paquetes capturados!), pero lo intentaré. Cam:X& Cam:Yson dos transmisiones de video RTSP transmitidas por dos instancias idénticas de Live555 WIS Streamer desde diferentes puertos. Los servidores 'A' y 'B' son las MAC de las dos NIC del servidor.
La secuencia de paquetes es la siguiente:
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'
No hay otros paquetes en la transmisión en este momento o alrededor de esta hora. Los paquetes Intel ANS no siempre coinciden con los ARP de la NIC, pero pensé en incluirlos para que estén completos.
El problema parece ser MUY sensible al tiempo, vemos estos ARP de "equipo" regularmente desde el servidor y solo una vez cada dos por tres nos causan un problema, como si hubiera un punto particular en el código de la pila de red que es sensible al Cambio de tabla ARP. No siempre es la misma instancia de transmisión la que falla y, en particular, la otra instancia (así como todo el resto del tráfico de red, HTTP, etc.) continúa funcionando bien.
Parece que las NIC en equipo "no deberían" ARP así a mitad de sesión, pero, por supuesto, no estarán al tanto de ninguna sesión cuando todo el tráfico sea UDP.
Respuesta1
Bueno aunque solo sea para dar un pococierreA esto, el cliente reconfiguró su tarjeta de red poco fiable y todo funcionó, por lo que, desafortunadamente para los curiosos, eso significa que nadie va a pagarle a nadie para que observe demasiado de cerca lo que se podría haber hecho para solucionar ese caso.