¿Cómo detectar si la red está cayendo paquetes UDP?

Tengo una aplicación de transmisión de video que funciona bien en mi oficina pero falla miserablemente en la ubicación del cliente. El síntoma es que cada dos segundos, dejo de recibir paquetes UDP durante 2 segundos, luego la secuencia se reanuda como si nada estuviera mal.

Ejecuté http://www.pingtest.net/ en la ubicación del cliente y resultó excelente. Sin paquetes descartados y baja latencia. La única diferencia que noté entre nuestras dos ubicaciones es que se ping google.caagota el tiempo en su ubicación pero funciona en la mía.

¿Cómo pruebo si la red en la que estoy bloquea los paquetes UDP entrantes? ¿Hay alguna forma de aislar quién deja caer los paquetes?

networking udp

— Gili
fuente

Suena como un problema de firewall para mí. ¿Tiene algún firewall de software o hardware?

— Pitto

¿No puede preguntar al cliente cuál es su configuración de red?

— Ramhound

@Ramhound, idealmente no. No quiero tener que profundizar en la configuración del enrutador de un cliente potencial cada vez que quiero hacer una demostración de mi producto :)

— Gili

Chicos, por favor expliquen sus votos negativos, de lo contrario no puedo responder.

— Gili

Respuestas:

Puede intentar establecer una conexión UDP con netcat.

En una máquina A fuera de la red del consumidor, ejecute:

nc -u -l -p 1234            # if using netcat-traditional
nc -u -l 1234               # if using netcat-openbsd (as pointed out by @JamesHaigh)

Tenga en cuenta lo -uque indica a netcat que use UDP. (Y también tenga en cuenta que hay diferentes versiones de netcat, que necesitarán el -pparámetro o no; las variantes de las dos más comunes (?), Incluidas ambas en Debian).

En el lugar del consumidor: nc -u [addr of machine A] 1234.

Intente enviar enviar algún texto, o incluso mejor usar tuberías para enviar un archivo entre ambas ubicaciones y hacer una diferencia después.

— mpy
fuente

Tu comando remoto falla por mí. La página de manual dice a -l“ It is an error to use this option in conjunction with the -p, -s, or -z options.”, por lo que he corregido el comando a uno que he probado para trabajar. Además, he cambiado 'ip' a 'addr' porque los nombres de host también se pueden usar, y en cierto sentido son una 'dirección'.

— James Haigh

@JamesHaigh: Estoy de acuerdo contigo en el punto addrvs. ipPero ahora con su comando, recibo un error: listen needs -p arg(también probé mis comandos dados en la respuesta ;)). Hay varios nc por ahí, si da más detalles como la versión de nc y / o su distribución, agregaré una nota a mi respuesta.

— mpy

¡Ah, claro, es una pena que no sean compatibles entre sí! :-( Ok, mi máquina remota es Debian. El nccomando predeterminado es enlace simbólico /bin/nc -> /etc/alternatives/nc -> /bin/nc.openbsdproporcionado por el paquete Debian netcat-openbsd. Mi máquina Ubuntu local también tiene nc.openbsdpor defecto. Ninguno aceptará -l -p. También he instalado ncaten ambas máquinas desde el nmappaquete Ubuntu / Debian. la máquina Debian más antigua, se ncatniega -l -p, pero ncaten Ubuntu acepta en ambos sentidos. Aunque la versión Debian debe ser antigua ya que molestamente no tiene la --sctpopción.: - /

— James Haigh

Ps ¿Cuál es su distribución y ncvariante? Noto que también hay un netcat-traditionalpaquete ' ', pero no lo he probado.

— James Haigh

@JamesHaigh: De hecho uso netcat-traditional(v 1.10-38) ya que se envía con Debian. Gracias por su sugerencia, incluí ahora ambas variantes en la respuesta.

— mpy

en el lado del servidor, establezca un servidor UPD con

iperf -s -u

en el lado del cliente, verifique la conexión UDP con

iperf -u -c <IP Address of Server>

— ckarrie
fuente

Esta es la verdadera respuesta. Requiere tener acceso al servidor en el otro lado. Pero le brinda retroalimentación directa de pérdida de paquetes. Y también puede usarlo para probar el ancho de banda TCP.

— DragonFax

Los netcatcomandos en la respuesta de mpy son útiles para fines de diagnóstico, pero estoy complementando esa respuesta con otro enfoque para su problema subyacente.

Puede valer la pena hacer que su aplicación recurra a SCTP , o incluso a TCP. En realidad, encontré esta pregunta porque estaba buscando cómo rechazar los paquetes UDP entrantes de los usuarios que usan más de su parte del enlace descendente cuando está congestionado, porque a diferencia de SCTP y TCP, UDP no tiene control de congestión, lo que hace que sea muy difícil priorizar el enlace descendente tráfico.

Tanto SCTP como TCP tienen control de congestión y funcionan muy bien con QoS, pero SCTP tiene el beneficio adicional sobre TCP que fue diseñado para aplicaciones de transmisión en tiempo real, lo que lo convierte en un buen reemplazo tanto para TCP como para UDP. En efecto, SCTP es el mejor de los dos protocolos de transporte más comunes.

No puede ser una mala idea tener un respaldo, en lugar de confiar solo en UDP. Incluso si solo recurre a TCP, al menos puede decir que está funcionando, tal vez no de manera óptima.

— James Haigh
fuente