Hello, I'm running Wireshark Version 2.0.2 (v2.0.2-0-ga16e22e from master-2.0). In some of the packets I'm analyzing, Wireshark is showing a Trailer as part of the VLAN tag. It shows up below the descriptions of the 3 VLAN sub-fields (Priority, CFI & ID) and the Type field (which, in this case, is IPv4). In one instance, this Trailer was 4 bytes long. In another it was much larger. In both cases, highlighting this Trailer field in the Packet Details pane showed that, in the Packet Bytes pane, the VLAN trailer was actually appended to the very end of the packet (not part of the VLAN field itself). Googling around I saw mention of Wireshark Bug 3587, that seemed to be relevant, but this bug report was dated in 2009, and it seemed unlikely that this bug was still present (unless... it reappeared?). Any insight would be awesome. Thx much... feenyman99 asked 11 Jun '17, 19:26  feenyman99 |
One Answer:
The dissection tree (the result of the dissection) is organized by relationship of the packet bytes to protocol layers, not by position of the bytes in the frame. Hence the trailer and/or checksum, although physically present at the end of the frame, are shown among the Ethernet/VLAN fields (and sorry, I cannot answer why it is shown in the VLAN portion rather than the Ethernet portion, I only remember that half of people thinks the VLAN should be treated as a separate layer and the other half thinks that it should be treated as part of Ethernet as IEEE wants it to be). The occurrence of trailer octets is related to the minimum size of the Ethernet frame - if the useful contents is smaller than that, trailer octets are used to obtain the minimum size. The bug you refer to deals with another issue - whether to handle the CRC in the end of the frame as CRC or as part of the payload, as the size of some types of payload is not expressed by any field of the frame. answered 19 Jun '17, 14:00  sindy |
