1
$\begingroup$

How can we manually read and interpret packets properly without using wireshark?

Now from the Ethernet header I know that the Destination MAC Address should be at the 5th byte (after converting bits/bytes). So from this data, I thought it would be 4a onwards. However, in reality it's 00:17:f2:d0:4c:82.

Same goes for the IP source destination. For instance, the source should be at 13-16 bytes. According to the readings, I guess it should be 0800 onwards. But in reality, it is on 0a 32 e7 85 but I don't get why? I am just confused on how to interpret this data correctly or maybe I am understanding the general header structure incorrectly.

https://ntquan87.wordpress.com/2015/08/17/reading-packet-hex-dumps-manually-no-wireshark/

Improve this question
$\endgroup$

1 Answer 1

Reset to default
5
$\begingroup$

My guess is that what you are seeing is a Level 2 Ethernet frame and therefore the preamble is missing. Also the Ethernet checksum seems to be missing. In this case everything seems to line up (the packet type inside the Ethernet frame, the IPv4 version, the IPv4 packet length, the packet type, i.e. TCP, inside the IP packet, ...). Then you'd read your packet as in the picture.

packet

The TCP payload is

474554202f20485454502f312e300d0a
557365722d4167656e743a2057676574
2f312e31312e340d0a4163636570743a
202a2f2a0d0a486f73743a207777772e
696574662e6f72670d0a436f6e6e6563
74696f6e3a204b6565702d416c697665
0d0a0d0a

and decodes to:

GET / HTTP/1.0
User-Agent: Wget/1.11.4
Accept: */*
Host: www.ietf.org
Connection: Keep-Alive

which is coherent with the fact that the destination port is 80.

Improve this answer
$\endgroup$
7
  • $\begingroup$ Because I had mistakenly swapped the labels for source and destination... My bad. I have updated the picture. There is no checksum because the IPv4 headers say that the IPv4 packet is 152 bytes long, i.e., it ends exactly at the end of your data. You can easily see that all the last bytes are part of the payload by their decoded version (it's an HTTP GET request). $\endgroup$
    – Steven
    Commented Apr 17, 2020 at 0:19
  • $\begingroup$ I don't know where you're getting these numbers from. The Ethernet payload (IPv4 packet) starts from the 15th byte. See: en.wikipedia.org/wiki/Ethernet_frame. Within the IPv4 packet, its length is in the 3rd and 4th byte. See: en.wikipedia.org/wiki/IPv4#Packet_structure . Therefore the length is 0x0098 (in hexadecimal), that is, 152 bytes. This is the length of the entire IPv4 packet (the box with the blue border in the picture). $\endgroup$
    – Steven
    Commented Apr 17, 2020 at 1:02
  • 1
    $\begingroup$ I understood where you're getting the numbers from: you are reading the diagram you posted in the wrong way! The length of the Ethernet destination address is not not 32 bits! It's 48 bits = 6 bytes... in the diagram, the "Destination MAC Address" field does not end at the end of the second line, but it continues on the third line as well (in the white space, until the "|" separator). The same holds for the source address (that starts from the empty space of the third line and ends in the forth line). I suggest using a less confusing diagram... $\endgroup$
    – Steven
    Commented Apr 17, 2020 at 1:09
  • $\begingroup$ I don't know why in your answers the source and destination mac addresses are swapped. That sounds like a good question for whoever gave you the answers... Regarding the IP packet, I don't get why you would want to remove the IP headers checksum?? From your diagrams, there are exactly 12 bytes in the IP packet before the "Source Address" field. This exactly matches my figure. $\endgroup$
    – Steven
    Commented Apr 17, 2020 at 13:49
  • 1
    $\begingroup$ The application layer protocol is HTTP. The flags are set to 000011000 in binary. If you look at a list of flags, you'll see that the 5th and 6th flag (corresponding to set bits) are ACK and PSH. $\endgroup$
    – Steven
    Commented May 15, 2020 at 1:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.