A quick WireShark scan of my network interface reveals a bunch of Ethernet packets which are less than 64 bytes in length. I know that WireShark strips off the trailing 4 byte CRC, but I still see some ARP packets with 42 bytes, some IGMPv3 with 54 bytes and some TCP with 54 bytes.

Is the 64-byte minimum Ethernet packet rule respected? What are the consequences of not respecting the rule?

  • 1
    Just to be clear, it's called an Ethernet Frame, not an Ethernet Packet. – joeqwerty May 24 '13 at 17:27

If you look more carefully, you will notice that all frames which are shorter than the minimum frame size (60 bytes without FCS) are frames which are transmitted by your machine. Received frames should be padded to 60 bytes without FCS; they contain the “Padding” field under “Ethernet II” in the Wireshark “Packet Details” window, which corresponds to those extra bytes.

At least in Linux, all transmitted frames which are shorter than 60 bytes should be automatically padded by the network driver (or even NIC hardware) before the transmission, but Wireshark does not show this, because frames are copied to the packet socket used by Wireshark before that padding is added.

Originally the minimum frame size was specified to make the CSMA/CD protocol used for the shared Ethernet medium work properly — reliable collision detection requires that the time needed to transmit a frame (which is proportional to its size together with all headers and preamble) must be greater than the signal propagation time between any two stations. Current Ethernet is in most cases not actually a shared medium (switches with full-duplex links do not perform collision detection). Technically enforcing a minimum frame size would not be required on a full-duplex link, but it is still done for compatibility reasons.

Since Gigabit Ethernet the 64-byte minimum frame size is no longer enough for collision detection when using practical cable lengths, and simply increasing the minimum frame size would lead to significant waste of bandwidth, therefore the Carrier Extension mechanism is introduced for half-duplex gigabit links (see also here for more information). Carrier extension is implemented in network hardware and not visible to software. In theory, using carrier extension makes enforcing the minimum frame size optional for half-duplex links, and with full-duplex links neither carrier extension nor minimum frame size are needed. However, the 64-byte minimum frame size is still kept, probably for compatibility with old software which could expect it.


This a one of those "it depends" questions I'm afraid

Is the 64-byte minimum Ethernet packet rule respected?

On what? a switch, between NICs etc?

What are the consequences of not respecting the rule?

Again on what and how?

Generally the worst case scenario is the packets get dropped, that's it, it won't set your data centre on fire (though don't quote me on that, not in any legal documents anyway :) ). If it hits a router it'll probably be reframed anyway on the way out and on a switch it'll either get through or not - pretty binary really.

  • 8
    Sounds like a Daily Mail title "42 byte package on a rampage burnt down my datacentre!" – NickW May 24 '13 at 16:51

I have also noticed that when wireshark is run on the system that is sending the packet, it can be displayed as fewer than 60 bytes. But, if you capture that particular packet on the receiving system, it will be padded out to 60 bytes with zeroes.

  • I just did this exact test; confirmed. – studog Oct 8 '19 at 19:21

Other packets that can be striped off by wireshark are VLAN packets (when your connection is tagged with VLAN iD). On linux you need to install the vlan package and on windows, your not sure if the NIC and its driver will drop the VLAN packet or not. see: https://wiki.wireshark.org/CaptureSetup/VLAN

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.