Frame Check Sequence Recorded in STP
This evening I was preparing to teach day 2 of my TCP/IP Weapons School class at USENIX. I decided I wanted to get a trace of Spanning Tree Protocol (STP) so I connected back to a box in my lab and ran Tshark. When I brought the trace back to my desktop to view in Wireshark, I saw the following:
How/why Tshark capture the FCS for this frame? I looked at other traffic (i.e., non-STP traffic) and did not see a FCS. The only other interesting aspect of this frame is the fact that it is pure 802.3 and not 802.3 with a LLC SNAP header, like this CDP frame:
I usually see 802.3 with a LLC SNAP header or just Ethernet II.
Does anyone have any ideas?
Comments
The length of your first example 802.3 frame is 52 bytes (38 + 14 ethernet header). This is 8 bytes under the minimum frame size of 60. This means we have a trailer padding of 8 bytes. In most captures, you would normally stop here.
In this case however, we have 64 bytes, which is 4 bytes of padding over and above the minimum 60 bytes. Wireshark just guesses that these extra 4 bytes might be an FCS instead of just gibberish. It proceeds to do a CRC32 and reports it as FCS.
The second packet in your example has a length of 359 bytes, which is way above the minimum 60 bytes. This means there is no need for pad-to-60 trailer bytes. There are no padding bytes for Wireshark to interpret as FCS.
The STP/LLC/SNAP protocols have no bearing on how tools like Wireshark handle the padding bytes.
Most of us already know this, but Wireshark is actually pretty smart in little intricate things like these. Most other products would have just reported the entire 12 bytes (64-52) as trailer padding and be done with it.
It is these little things that make Wireshark so cool.
Your explanation makes sense, but why would the "FCS" not be more 00s, and why does Wireshark report the FCS as "correct"?
When dealing with short payloads, many NICs pass only the first 60 bytes up the driver stack to Wireshark. It seems yours passed on the FCS (the CRC) as well.
Wireshark just guesses that the 4 bytes over and above the trailer padding might be a valid CRC passed up from the NIC. So, it proceeds to compute a 32-bit CRC on the first 60 bytes. It then compares the computed value against what was on the wire. It declares it to be correct if they matched.
As you point out, some NICs might even zero out the CRC (FCS). In that case, Wireshark will just declare the CRC to be wrong !
I just cross checked with the Wireshark code
Newer NICs can/do perform checksum offloading. The network driver won't calculate the checksum itself but simply hand over an empty (zero or garbage filled) checksum field to the hardware.
Also, checksum offloading often causes confusion as the network packets to be transmitted are handed over to Wireshark before the checksums are actually calculated. Wireshark gets these "empty" checksums and displays them as invalid, even though the packets will contain valid checksums when they leave the network hardware later.
You might want to disable checksum validation in Wireshark. Otherwise you get annoying errors.
I have other questions in the same context:
1) why wireshark detecte tailer some times and another no
2) who I can send a frame without padding in order to send a frame less than 64 bytes ?