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?

Blomquist

No code, so expect large downvotes. If this is not misuse of NUL-terminated strings, or functions that require them, I'll eat my mouse. – Pence

No strings I sent a buffer of raw data bytes and it is still doing it. Even with a simple sendto function for the buffer of unsigned chars. I'll post example code – Blomquist

'These must be added on from padding at the Linux Kernel layer?' Think about how many Linux instances are running around the world. Then estimate how many are using an app/service/daemon/whatever that uses UDP or a protocol built on it. Now estimate the chances that your problem is with the OS, and not your code..... – Pence

As a rule, when dealing with widely used libs or functions, assume any unexpected behavior you see comes from either invalid expectations or coding errors on your part until you can (strongly) prove otherwise. – Metatarsal

At least show us a screenshot of Wireshark after you've clicked the mouse on the datagram body so we can see what Wireshark thinks those two bytes are (for example they could be part of an outer protocol). – Jayson

@MartinJames vid or it didn't happen! – Matt

....with chilli and garlic sauce. – Pence

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.

Lynnelle

Such a detailed answer, the extra bytes that originally led me to believe it was my code. Thanks for educating me, I never seen this before and it made me jump to foolish assumptions. – Blomquist

Good answer, but it doesn't quite answer the question: "These must be added on from padding at the Linux Kernel layer"? Two options: (a), the kernel constructs a small 58-byte Ethernet frame (without FCS, of course), and tells the hardware to transmit 58 bytes, so the hardware inserts 2 padding bytes before the FCS, or (b) the kernel constructs a minimum-sized 60-byte frame, including two padding bytes, and tells the hardware to transmit 60 bytes (plus FCS, of course). I don't suppose it matters, since the receiver can't tell the difference (I think), but it would be nice to know. – Gambrill

FWIW, another caveat are VLAN-IDs - i.e. when VLAN tagging is enabled, this adds 4 bytes that might show up in a packet capture. And since (usually?) a host doesn't add the VLAN-ID in its outgoing packet, itself - it can't account for those extra 4 bytes - such that the receiving host receives minimal packets that are padded to 68 bytes (including the FCS). – Ytterbium