Estoy trabajando con una pieza de hardware que genera un flujo de datos empaquetado en paquetes UDP. Estos se envían en un enlace Ethernet de 40 Gb dedicado a otra pieza de hardware del receptor. No hay concentradores ni conmutadores involucrados, solo un único emisor y un único receptor.
Recientemente desconectamos el hardware del receptor y conectamos ese extremo a una estación de trabajo Linux básica para recibir el flujo de datos con el software. Puedo poner en marcha el hardware del remitente y, con Wireshark ejecutándose en la estación de trabajo receptora, puedo ver exactamente los datos que se supone que debo ver. Sin embargo, si enciendo una aplicación separada en el receptor que hace UDP recvfrom(), no puede ver los paquetes UDP que Wireshark puede ver, solo obtiene tiempos de espera de recvfrom(). Me conecto exactamente a la misma dirección IP y puerto que Wireshark informa como el destino de los paquetes. La dirección IP es una subred privada 192.168 y el puerto está en los 4000, por lo que es "reservado" pero no "conocido". Establecer la dirección IP en INADDR_ANY no hace ninguna diferencia. Si tengo Wireshark ejecutándose cuando intento hacer la recepción UDP no hace ninguna diferencia.
El software que intenta recibir funciona si el remitente es otra aplicación de software (es cierto que envía a alguna otra NIC en la estación de trabajo). Compruebo el estado de devolución de cada llamada (socket(), setsockopt(), bind(), recvfrom()) y todas afirman tener éxito.
El NIC que recibe los datos es un Mellanox ConnectX-4 (creo) que está configurado en modo Ethernet de 40 Gb. La MTU se establece en 9000, aunque los paquetes en el flujo de datos son mucho más pequeños (100-200 bytes).
¿Qué condiciones harían que un flujo de paquetes fuera visible para Wireshark pero no para otro software de aplicación? ¿Puede haber una configuración de NIC que no sea correcta? ¿Podría haber indicadores en los encabezados de Ethernet/IP/UDP que sean cuestionables y no formen parte de la pila? ¿Dónde debo buscar a continuación?
Como se señaló en los comentarios anteriores, el problema fundamental era que el hardware de envío usaba una dirección MAC de destino que no era la de la NIC de recepción. Resulta que, al igual que la dirección IP, estaban codificados en el hardware de envío. Y el hardware no era capaz de usar ARP para resolver. Descubrir esto implicó la verificación cruzada de la salida de "ip addr show" con lo que informaba Wireshark. Afortunadamente fue posible programar una nueva dirección MAC para que la use el remitente. La lección aquí, si la hay, es no asumir nada, verificar todo.