¿Cómo podemos leer e interpretar manualmente los paquetes correctamente sin usar Wireshark?
Ahora desde el encabezado de Ethernet Sé que la dirección MAC de destino debe estar en el quinto byte (después de convertir bits / bytes). Entonces, a partir de estos datos, pensé que sería 4a en adelante. Sin embargo, en realidad «s 00:17:f2:d0:4c:82.
Lo mismo ocurre con el destino de la fuente IP. Por ejemplo, la fuente debe estar en 13-16 bytes. Según las lecturas, supongo que debería ser 0800 en adelante. Pero en realidad, está en 0a 32 e7 85 pero no entiendo por qué. Estoy confundido sobre cómo interpretar estos datos correctamente o tal vez estoy entendiendo la estructura general del encabezado incorrectamente.
https://ntquan87.wordpress.com/2015/08/17/reading-packet-hex-dumps-manually-no-wireshark/
Respuesta
Supongo que lo que está viendo es una trama Ethernet de nivel 2 y, por lo tanto, falta el preámbulo. También parece que falta la suma de comprobación de Ethernet. En este caso, todo parece alinearse (el tipo de paquete dentro del marco de Ethernet, la versión de IPv4, la longitud del paquete de IPv4, el tipo de paquete, es decir, TCP, dentro del paquete de IP, …). Entonces «leerías tu paquete como en la imagen.
La carga útil de TCP es
474554202f20485454502f312e300d0a 557365722d4167656e743a2057676574 2f312e31312e340d0a4163636570743a 202a2f2a0d0a486f73743a207777772e 696574662e6f72670d0a436f6e6e6563 74696f6e3a204b6565702d416c697665 0d0a0d0a y decodifica a:
GET / HTTP/1.0 User-Agent: Wget/1.11.4 Accept: */* Host: www.ietf.org Connection: Keep-Alive lo cual es coherente con el hecho de que el puerto de destino es 80.
Comentarios
- Porque cambié por error las etiquetas de origen y destino. . Mi mal. He actualizado la imagen. No hay suma de comprobación porque los encabezados de IPv4 dicen que el paquete IPv4 tiene 152 bytes de largo, es decir, termina exactamente al final de sus datos. Puede ver fácilmente que todos los últimos bytes son parte de la carga útil por su versión decodificada (es ' una solicitud HTTP GET).
- Yo no ' No sé de dónde ' obtiene estos números. La carga útil de Ethernet (paquete IPv4) comienza desde el byte 15. Consulte: es .wikipedia.org / wiki / Ethernet_frame . Dentro de la I Paquete Pv4, su longitud está en el tercer y cuarto byte. Consulte: en.wikipedia.org/wiki/IPv4#Packet_structure . Por tanto, la longitud es 0x0098 (en hexadecimal), es decir, 152 bytes. Esta es la longitud de todo el paquete IPv4 (el cuadro con el borde azul en la imagen).
- Entendí de dónde ' obtiene los números de: estás leyendo el diagrama que publicaste de manera incorrecta. ¡La longitud de la dirección de destino Ethernet no es de 32 bits! Es ' 48 bits = 6 bytes … en el diagrama, la " dirección MAC de destino " El campo no termina al final de la segunda línea, pero continúa en la tercera línea también (en el espacio en blanco, hasta que " | " separador). Lo mismo ocurre con la dirección de origen (que comienza en el espacio vacío de la tercera línea y termina en la cuarta línea). Sugiero usar un diagrama menos confuso …
- No ' no sé por qué en sus respuestas se intercambian las direcciones mac de origen y destino. Suena como una buena pregunta para quien le dio las respuestas … Con respecto al paquete IP, ' no entiendo por qué querría eliminar la suma de comprobación de los encabezados IP. De sus diagramas, hay exactamente 12 bytes en el paquete IP antes del campo " Dirección de origen ". Esto coincide exactamente con mi figura.
- El protocolo de la capa de aplicación es HTTP . Las banderas se establecen en 000011000 en binario. Si observa una lista de banderas , ' verá que la quinta y sexta bandera (correspondientes al conjunto bits) son ACK y PSH.