Why Packet Slicing Displays 4 Bytes Less Than Configured

When packet slicing packets and recording the subsequent output in Wireshark on a windows Laptop/PC, you will notice that you’re missing 4 bytes of data. For example, when slicing at 64 bytes you will only see a maximum of 60 bytes in Wireshark when using this configuration:

gsop alias GS-Slice slicing protocol none offset 64 port-list gsg1

Note that I have chosen “none” as the starting point which essentially means that the offset starts from the beginning of the Ethernet Frame.

This shows up with only 60 bytes displayed (not what we were looking for!) as follows:

The reason for this is that the GigaSMART module is slicing the packet (read: Ethernet frame) correctly as it includes the CRC (aka FCS) on the packet. When the packet is received by the Windows NIC card driver it actually removes the CRC from the packet (this is actually performed by the WinPcap driver) before passing it to the Wireshark program for display. It’s probably worthwhile mentioning that the Windows NIC driver removes VLAN tags in the same way which is why they don’t show up in Wireshark either (unless loaded from a pcap file).

So if I change the slicing offset to 68 (i.e. 64 + 4) with the following configuration:

gsop alias GS-Slice slicing protocol none offset 68 port-list gsg1

…we get within Wireshark the results that we expect:

You will notice that there are some packets (e.g. packet #3) that are less than 64 bytes which is because they are less then 64 bytes on the wire. It’s worth mentioning at this point that the windows driver (WinPcap) also removes all the padding, as the Ethernet standard dictates that Ethernet frames must be a minimum of 64 bytes. This would obviously be different if displayed in a more advanced protocol analyzer.

The packets do look odd as Wireshark correctly points out that the IP Length field differs from the packet captured, so to get around that you can alter the snaplen when capturing – to see how to do that you can read about it here.

To illustrate this, the below shows the same packets displayed in Wireshark with a snaplen of 48 (note that the snaplen has to be less than the sliced packet size received by Wireshark):