Ethernet frame parser
Decode an Ethernet II frame: destination/source MAC, EtherType (unwrapping one 802.1Q VLAN tag if present), and payload length. IEEE 802.3 LLC/SNAP framing is not handled, only Ethernet II.
Ethernet frame parser decodes an Ethernet II frame into destination MAC, source MAC, EtherType and the payload byte count, naming IPv4, ARP and IPv6 where it sees them. One 802.1Q or 802.1ad tag is unwrapped, printing PCP, DEI and VLAN ID before the inner type. Anything under 14 bytes is refused with the length you gave.
Questions
What does it show?
Destination and source MAC in colon notation, the EtherType with a name when it knows one, and the payload length in bytes. IPv4, ARP, IPv6 and both VLAN tag types are named; anything else is shown as a hex EtherType marked unknown.
Does it handle VLAN tags?
One tag, yes. If the EtherType is 802.1Q or 802.1ad it reads the tag control information and prints PCP, DEI and the VLAN ID, then reports the inner EtherType that follows. A second stacked tag is not unwrapped, so on Q-in-Q you see the outer tag and the inner type only.
Does it parse the payload too?
No, it stops at the header and counts the remaining bytes. To go further, take the payload bytes and drop them into the IPv4 / TCP / UDP header parser, which expects exactly that. If the payload is a TLS record rather than an IP packet, the TLS record parser does the same job.
Why did it refuse my file?
A frame shorter than 14 bytes cannot hold two MAC addresses and an EtherType, so it stops with the minimum and the length you gave. Note also that only Ethernet II framing is handled; IEEE 802.3 with LLC or SNAP headers is not.
Is the frame check sequence included in the payload count?
If your capture kept it, yes. The payload figure is the number of bytes left after the header, so any trailing FCS or padding your capture tool preserved is counted in it. The tool does not check an FCS and does not try to work out whether one is present.