UDP is adding bytes to end of datagram?

Question

I have a Linux UDP Server written in C and I am sending a UDP datagram of 16 bytes. All the data is received correctly by the client, but the wireshark log is showing that two extra bytes are being added:

00 16 00 00 c8 44 01 14 01 01 02 01 02 00 00 10 00 00

The two bytes are all zeros, I'm not sure where they are coming from, I have the data of 16 bytes sent in my sendto() function.

These must be added on from padding at the Linux Kernel layer? Is there anyway to stop this from happening?

Screen shot of wireshark, apparently this is Ethernet padding bytes... Why are they here?

Answer 1

the Ethernet frames need to be minimum of 64 octets, including the 4 octets of Frame Check Sequence (FCS) that is not shown in the screenshot. Without those 2 zero padding octets, that frame would be only 62 octets long. Also notice that they're not in the UDP packet, they're outside. The length of the UDP frame on the outside is given as 24, this includes 16 octets of the data that you sent; the remaining 8 octets are 4 16-bit numbers: source port, destination port, length and checksum. The Ethernet padding bytes are outside both the UDP and the IP framing.

The reason for the minimum 64-octet frame length is old - Ethernet was originally designed for bus topology, where media access was regulated with a method called carrier-sense multiple access with collision detection (CSMA/CD). Any device may transmit on the bus at any time when the bus is free, but they must monitor the bus for simultaneous transmissions. If a collision occurs, then each currently sending party backs off for a random delay. The 64-byte minimum was set so that the sending device would notice a collision on a cable run that is hundreds of metres long before it has finished sending the frame.

From Wireshark documentation via Google search for "wireshark minimum ethernet frame":

Ethernet packets with less than the minimum 64 bytes for an Ethernet packet (header + user data + FCS) are padded to 64 bytes, which means that if there's less than 64-(14+4) = 46 bytes of user data, extra padding data is added to the packet.

Beware: the minimum Ethernet packet size is commonly mentioned at 64 bytes, which is including the FCS. This can be confusing as the FCS is often not shown by Wireshark, simply because the underlying mechanisms simply don't supply it. [...]

---

By the way this is in no way related to the C programming language.