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?


Anonymous said…

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"?
Anonymous said…
The FCS on the wire is a 32-bit CRC on the entire frame. In case of your first packet, the CRC is computed over the entire 60 bytes including the 8-byte trailer padding (which has been zero-ed in this case).The CRC is tacked on to the 60 bytes to make the minimum 10/100 ethernet size of 64 bytes.

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
Ryan Russell said…
Yep. Ethernet has a minimum frame size of 64 bytes. You'll get bits of leftover memory with some Ethernet drivers to pad out the rest of the frame.
Anonymous said…
One side point about checksums in Wireshark.

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.
Unknown said…
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 ?
Anonymous said…
This comment has been removed by a blog administrator.

Popular posts from this blog

Zeek in Action Videos

MITRE ATT&CK Tactics Are Not Tactics

New Book! The Best of TaoSecurity Blog, Volume 4