How to decode Ethernet Frames?

May 9, 2011

Ethernet is the most common protocol used for communication with in LANs. Thus, most of the people doing frame analysis have to know the structure of Ethernet frames and different fields used in it. This will help them in better understanding of the traffic originating or coming to the LAN as well as diagnosing any problem that might occur. Thus, we have decided to do a  post for our readers that will discuss the method of decoding Ethernet frames using Ipv4 and UDP protocol.

Consider a packet captured using WireShark

00 00 5e 00 fa ce 00 16  76 d2 28 38 08 00 45 00 00 1d 7b bd 00 00 80 11  3a e5 c0 a8 01 a6 c0 a8  01 37 23 82 23 83 00 09  33 a9 01

Before proceeding any further, it should be noted that the above frame is shown using HEX values. It is advised that you review the methods for converting HEX to decimal or binary before proceeding any further.

Image courtesy of Wikipedia

Using the above picture, we decode this frame as follow:

00 00 5e 00 fa ce: These 6 bytes are the Destination MAC Address

00 16 76 d2 28 38: These 6 bytes show the Source MAC Address

08 00: Tells the version of Ethernet Type. In our case it is Ether Type II.

45 00: ‘4’ shows the version field like if we are using Ipv4 or Ipv6. Since we are using Ipv4, the value is ‘4’ (If we were using Ipv6 then it would have been ‘6’). The next byte shows the number of bytes in header, which in our case is ‘5’ (we are not using option field). The next two bytes are ‘00’ showing that we are not using “Differentiated services”.

00 1d: These 16 bytes shows the length of the entire datagram. This includes the UDP length, data and IP header. The IP header is of 20 bytes when we are not using option field. This can be calculated as explained below:

4 bits for version field and 4 bits for header length makes: 1 byte

Differentiated Services: 1 byte

Total Length: 2 bytes

Identification Field: 2 bytes

3 bits for Flag Field and 13 bits for Fragment Offset Field: 2 bytes

Time to Live: 1 byte

Protocol Field: 1 byte

Header Checksum: 2bytes

Source IP address: 4 bytes

Destination IP address: 4 bytes

Options Field: 0 bytes

——————

Total Bytes: 20 bytes

7b bd: These two bytes are for identification field and is primarily used for uniquely identifying fragments of an original IP datagram.

00 00: These values corresponds to Flag Field and Fragment Field as you can see in the picture.

80 11: Here ‘80’ shows the TTL (Time to live for that frame) and ‘11’ shows that we are using UDP protocol in our datagram(‘17’ in decimal for UDP).

3a e5: These 4 bytes show the checksum of IP-Header. How to calculate the IP-header checksum, this can be found by clicking here.

c0 a8 01 a6: These 4 bytes show the Source IP Address

c0 a8  01 37: These bytes corresponds to Destination IP Address

23 82: These values show the Source port like from where frame is originated

23 83: These bytes points to the Destination port number.

00 09: These four  bytes show the length for UDP datagram. It includes both UDP header and data. The length is calculated as:

Source Port: 4 bytes

Destination Port: 4 bytes

Data: 1 byte

—————–

Total Bytes: 9 bytes

33 a9: These four bytes corresponds to UDP Checksum. The method for calculating UDP checksum is explained here.

01: It is the data that we have sent.

You would be wondering that the minimum frame size for Ethernet is 64 bytes, but here I have only shown 43 bytes, well you can add the 4 bytes which is the CRC for Ethernet (it is added automatically at data link layer) and it makes it 47 bytes. Still 17 bytes are missing (64-47=17). They are added by applying zero padding. This is done automatically each time the Ethernet frame size is less than 64bytes. This zero padding is not the part of any calculations required for calculating checksum for IP header or UDP Checksum or length of UDP Datagram.

If you have any queries, please do let us know through your comments.

  • Awanishtiwari82

    hi, how each data byte is manupulated to generate crc

  • Rapdummy

    For calculating the UDP checksum, is the rest of the data (including the PTP header) used?

    • http://www.nerdcrunch.com NerdCrunch

      UDP Check-sum is optional. If you want to calculate UDP check-sum then only header portion of UDP is used

  • Prabhushefali

    Hi,
    Can you please tell how do I calculate the payload size (data and padding) from the given frame size i.e. 54 bytes in my case. This is the observation done on wireshark.

    • http://www.nerdcrunch.com NerdCrunch

       On Ethernet, minimum frame size can be 64 bytes. If you have 54 bytes then you have to add zeroes to make it to 64 byte.

  • Philip Greig

    For the 00 1d field you say it’s 16 Bytes but 1d is 29 Bytes?

    • http://www.nerdcrunch.com NerdCrunch

      29 is the value not the byte size of this field.
      0=4 bytes
      0=4 bytes
      1=4 bytes
      d=4 bytes

      Hence 16 bytes. Hope it clears :)

      • whiteTigr

        But it’s 2 bytes field (or 16 bits). I guess it’s just typo.

  • http://sexon.lt SexOn.lt

    It’s very complicated :(

  • engineer5

    I am using avb ethernet (audio signals transmitted over ethernet). I want to decode the packets into audio samples that sent from talker. I did not find any tool. Do you have any idea?

  • satheesh

    Can you please tel how to calculate the data length from your example .
    length of datagram = length of ip header + length of data

    How we can find the exact data which is padded with zeros (i.e i would like to know which one is data part and rest are padded elements )

    • http://www.nerdcrunch.com NerdCrunch

      Hi,

      You can capture data via wireshark. There are many tutorials out there that can help you there. As for length of datagram, please note that it is length of header of datagram + length of data. Please consult datagram diagram on internet for further better understanding. And lastly, as mentioned earlier, please make use of wireshark to capture any udp packet and then you can calculate each field on paper easily.

      Do let me know if I can assist you further in any way.

  • erol alkan wannabe

    If i am right then we can see an UDP packet –> IP datagram –> Ethernet frame on the picture. Let’s say an application “made” the UDP packet, then who puts the UDP packet into the IP datagram then into the Ethernet frame? Windows drivers? The network adapter? My router?

  • rockstrongbow

    Your interpretation of EtherType is not correct. 0x0800 is actually IPv4.

  • Ameyaa Chandras

    FF FF FF FF FF FF 50 7B 9D 4B 1C C3 08 06 00 01 08 00 06 04 00 01 50 7B 9D 4B 1C C3 00 00 00 00 00 00 00 00 00 00 A9 FE E1 19
    can u decode the packet and let me know the detailed info?????

    it is not matching with the format explained above.