Resumen

  • El RFC 1761 describió el archivo Snoop Version 2 de Sun para que programas distintos pudieran generar y analizar la misma captura.
  • Sus registros separan tamaño original, bytes guardados y pérdidas acumuladas; un cero en estas últimas puede significar que el capturador no sabía contarlas.

El equipo que recoge los paquetes puede entregar el archivo al turno siguiente y, por fin, irse a dormir. Ese relevo cotidiano explica por qué Brent Callaghan y Robert Gilligan publicaron en febrero de 1995 el RFC 1761: el formato Snoop de Sun debía poder abrirse también con programas ajenos. Pero el relevo tiene una trampa. Si un paquete llegó entero y el archivo guardó sólo el comienzo, quien lo abra mañana recibirá una respuesta con la última frase arrancada. El formato permite detectar el corte; nadie debería mandar al equipo a reparar un fallo basándose en la frase ausente.

La cabecera ocupa dieciséis octetos. Primero aparece una marca de ocho: los caracteres snoop y tres ceros. Después llegan la versión 2 y el tipo de enlace, dos enteros de cuatro octetos. Ethernet utiliza el código 4; IEEE 802.3, el 0. No es una diferencia decorativa. Los datos de cada paquete empiezan por la cabecera de enlace, y esa cifra le indica al programa cómo interpretarla. La tabla incluye además Token Ring, HDLC, FDDI y otros medios. Un analizador que empiece en el lugar equivocado podrá producir una explicación preciosa de los bytes equivocados.

Tras la cabecera vienen registros de longitud variable. Cada uno abre con seis enteros de 32 bits, veinticuatro octetos antes de los datos. El primero, longitud original, mide el paquete recibido de la red. El segundo, longitud incluida, mide la porción que quedó archivada. Cuando esta última es menor, hubo recorte. Ver el principio de un paquete en pantalla no devuelve el final que se descartó para ahorrar almacenamiento. Ahí la captura confiesa su propia tijera.

El tercer entero indica la longitud completa del registro, incluidos los veinticuatro octetos iniciales, los datos y el posible relleno. Sirve para saltar exactamente al registro siguiente. También hay una regla de orden: todos los enteros se guardan con el byte más significativo primero. Son detalles que suelen perder el concurso de titulares, pero de ellos depende que dos programas lean la misma secuencia. Si se confunden longitud de datos y longitud del registro, el relleno puede disfrazarse de paquete.

El cuarto entero parece contundente hasta que se lee la letra pequeña del propio RFC: pérdidas acumuladas cuenta los paquetes perdidos por el sistema de captura desde el primer registro. Algunos programas no pueden llevar esa cuenta y ponen cero. Un cero, por tanto, puede describir una medición sin pérdidas o la ausencia de medición. Es un número que necesita su ficha técnica antes de entrar en un informe. Y habla del capturador, no de si la aplicación de destino recibió correctamente nada.

Los dos últimos enteros sitúan la llegada del paquete en segundos desde el 1 de enero de 1970 y en microsegundos. Permiten ordenar lo guardado. Para explicar una avería real habrá que unir esa línea temporal a otros indicios, especialmente cuando faltan bytes o paquetes. El mérito del RFC fue dejar un archivo que otros podían leer y campos que impiden confundir fácilmente el contenido de ese archivo con el universo entero del tráfico.