 | 1 | initial version |
Since the Ethernet header does not include a length field, Wireshark needs to figure out the purpose of the data on its own. For "normal" frames it would be one of the following formats:
[ETH][PAYLOAD][FCS]
[ETH][PAYLOAD][PADDING][FCS] (when the frame would be less than 64 bytes on the wire)
By dissecting the "payload", Wireshark knows how much data was actually upper protocol data, so the rest should be part of the ethernet layer. It will then use some heuristics to decide what part of that data was padding and whether there was a FCS (which will be stripped by most NIC's before Wireshark gets to see the packets), meaning Wireshark sees:
[ETH][PAYLOAD]
[ETH][PAYLOAD][PADDING] (when the frame would be less than 64 bytes on the wire)
Now when there is extra data that can't be padding, Wireshark will show it as "trailer" data. There are systems that add stuff to the ethernet packet as trailer. For instance, packet brokers often add timestamps and port information into an ethernet trailer. F5 loadbalancers also add trailers to provide information on the Virtual being used for the traffic for instance.
In your case, there is no dissector dissecting the trailer bytes into some protocol headers, so all Wireshark can do is display it as a (general) trailer. It then also (incorrectly) assumes that the last 4 bytes are the FCS and so it tries to verify it's correctness. However, mot likely, the real FCS has already been stripped by the NIC.
You can fiddle with the "Ethernet" protocol preferences to make Wireshark not assume there was a FCS and just display the trailer data as "trailer".
The interesting question is "Where and how was this capture taken?". As some system must have included the extra trailer for some reason. Do you know if there was a loadbalancer or packet broker involved?
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.