¿Cómo verificar el contenido del paquete devuelto en ICMP Ping / Echo?

Question

Al validar los ecos de ping, parece que las utilidades / bibliotecas a menudo solo verifican la suma de verificación del paquete, y en realidad no confirman que la carga útil enviada coincide con la carga que se devolvió. Por ejemplo, el analizador ICMP de Wireshark solo busca sumas de verificación incorrectas, y eso es todo lo que Ruby net- ruby también.

Estoy depurando un problema de controlador de red de bajo nivel, y necesito confirmar que los datos no están siendo maltratados cuando se reciben, así que quiero probar mi controlador usando una solicitud de bajo nivel como ICMP Echo . Sin embargo, mis herramientas Ping existentes son insuficientes, porque temo que, si bien la suma de comprobación puede coincidir con los datos contenidos en la respuesta de eco, los datos en la respuesta de eco no coinciden con los datos en la solicitud de eco. Entonces, aunque ambos tienen sumas de verificación válidas (no hay error en el código de suma de verificación), hay un error en la parte de recepción de datos, de modo que mi controlador no recibe lo que el host cree que está enviando.

¿Cómo puedo verificar la carga útil del eco para confirmar que es lo mismo que envié? Si hay un "ping paranoico independiente" utilidad que podría usar, también está bien, solo necesito poder variar las longitudes y frecuencias de ping ya que solo veo el problema cuando la red se inunda.

Lo preferiría en forma de una biblioteca / fragmento de Ruby, pero cualquier idioma o aplicación independiente es aceptable, siempre que pueda calzarlo para que se ejecute en Windows.

¡Gracias!

Answer 1

@Tom: Gracias por la respuesta. Dijiste:

  

El receptor vuelve a calcular una suma de verificación de los datos y la compara con la que se envió.

Pero también dijiste:

  

La suma de comprobación ICMP no incluye los encabezados TCP, solo el tipo ICMP, el código, la suma de comprobación y los campos de datos.

El tipo ICMP es diferente entre la solicitud / respuesta de eco (una es 0, la otra es 8). Entonces, por definición (y en la práctica, si echa un vistazo a Wireshark) las sumas de comprobación ICMP no coinciden entre la solicitud de envío y la respuesta de eco.

Mi problema era que si las utilidades / bibliotecas de ping verificaban algo (y a menudo no lo hacían), solo verificaban para asegurarse de que la suma de verificación coincidiera con los datos. Parece que rara vez las personas verifican realmente los datos enviados con la respuesta de eco para asegurarse de que las dos cargas son idénticas. Es posible que tanto una solicitud como una respuesta puedan tener sumas de verificación válidas, pero diferentes cargas útiles, y la mayoría de las rutinas de Ping que he visto no han verificado tal condición (pero resulta ser el tipo de error que tengo en mi dispositivo en este momento).

Gracias por mirar mi pregunta y responder, sin embargo, es muy apreciada.

@All:

En respuesta a mi propia pregunta, pude usar el robusto . Net Ping , ya que me da acceso inmediato al búfer de respuesta recibido (a diferencia de la mayoría de las otras bibliotecas de Ping que encontré).

Answer 2

Creo que te estás perdiendo el punto de la suma de control. El propósito de la suma de verificación es validar que los datos estén intactos. El remitente calcula la suma de comprobación de los datos y la transmite con los datos. El receptor vuelve a calcular una suma de verificación de los datos y la compara con la que se envió. Si no coinciden, entonces los datos no están intactos o uno de los dos lo está calculando mal. La mayoría de las veces, las sumas de verificación incorrectas no generan paquetes descartados porque hay muchas pilas de protocolos rotas y, por supuesto, los manipuladores de paquetes y eso no arregla la suma de verificación, pero si ambas partes lo hacen correctamente, entonces la verificación de suma de verificación le dice que los datos están intactos.

¿Está mirando la suma de verificación TCP o la suma de verificación ICMP? La suma de comprobación ICMP no incluye los encabezados TCP, solo el tipo ICMP, el código, la suma de comprobación y los campos de datos. Una falla de suma de verificación TCP no necesariamente significa que el contenido de ICMP no esté intacto, sino que podría significar que los encabezados TCP se enredaron (quizás por un NAT roto).