Now we can see each line is 4 bytes, 23 bits. And starting from zero and counting the bytes we find Protocol in the ninth field.
The first two fields are divided into half bytes, call nibbles, 4 bits each. Just count them both as one byte.
We’ll cover what they do later and why the authors who wrote the protocol divided them up.
Most fields in the protocol header break on byte, or nibble (half byte) boundaries.
There are a few notable examples, which we’ll cover as we look at bitmasking. Bitmasking can be simply defined as showing only the bits you need to see and masking out the others.
The same principles apply to any protocol. If there’s a header, you can parse it.
Getting yourself a good set of diagrams, in the format and layout YOU like is really going to help you. Unless you’re in the rare position of doing nothing but analyzing packets all day, you’re not going to memorize the protocol headers, probably.
But from practice, you will remember the embedded protocol is in the ninth byte offset from zero in the IP header, or the flags bits are in the 13th byte in the TCP header, or the IP version is in the most significant 4 bits of byte 0 in the IP header.
Without bunny trailing into big endian and little endian, for the purposes of packet inspection just remember that network byte order always starts from the left (you start counting at the leftmost bit and move right).
So to make this practical (and start at the beginning), the first byte of the IP header (byte zero) is split in half. The first four bits are the IP
The second 4 bits, or nibble, is the header length. This is a value multiplied by 4. A normal IP header, with no options, is 20 bytes, so this should normally be 5.
Now that’s your first visual clue when looking at a packet capture in hex. If the capture included the Ethernet header and you’re looking for the start of the IP header, it SHOULD, but isn’t always, be 45.