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.