This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

FCS check is not displayed

0

I cannot seem to configure Wireshark version 1.6.2 to identify an Ethernet FCS. I am using Wireshark to help verify the contents for a Frame Generator application that I am developing. The application is dumping out the contents of Ethernet frames in a "text dump file" in hex format that is able to be read into Wireshark . I simply input the "text dump file" into Wireshark by clicking File->Import->(file name) with the format set to "hexadecimal" and the encapsulation set to "Ethernet".

Below is the content of my "text dump file" that includes an Ethernet/IPv6/UDP frame with 11 bytes payload and a broken FCS (CRC-32 is "b1 0a 91 2f "):

00000000   0d f3 0b b9 4a bb bf ec 
00000008   ff 49 88 32 86 dd 40 4d 
00000010   f4 da 8f d0 11 a4 8e ef 
00000018   07 33 4f 18 39 03 f5 89 
00000020   2b 66 38 68 f1 97 03 ab 
00000028   e1 7d 15 4a 07 c9 ba dd 
00000030   42 1c 47 dc 0b de 7f 76 
00000038   ef 4e 00 13 00 04 ad da 
00000040   68 ec 4e 61 90 8d 1e 26 
00000048   c1 b1 0a 91 2f

After importing the frame, I see the entire expected Ethernet frame. In my example, I see all the Ethernet/IPv6/UDP fields and 11-byte payload as expected, but I do NOT see the 32-bit FCS identified & checked by Wireshark.

Looking through some of the posts in this forum, it seemed as if the Edit->Preferences->Protocols->Ethernet->"Assume Packet has FCS" would help, but it did not solve my FCS issue.

Looking through my Wireshark preferences file, I see the following settings that look interesting, but they do not seem to help:

erf.ethfcs: TRUE  
eth.assume_fcs: TRUE

In Wireshark documentation, I also see information about a CyclicRedundancyCheck (CRC) algorithm to detect transmission errors and a FrameCheckSequence field, but I am not sure how to enable these features.

  • Is there a Ethernet FCS/CRC configuration switch that I need to enable?
  • Do I need to create or use a a Wireshark plug-in extension?
  • Do I need to create a User Encapsulation Type?
  • Does this have something to do with libpcap?

asked 12 Sep '11, 11:41

steved's gravatar image

steved
1111
accept rate: 0%

edited 12 Sep '11, 23:38

helloworld's gravatar image

helloworld
3.1k42041


One Answer:

2

Wireshark's heuristics for detecting the presence of an FCS in an Ethernet packet rely, for packets with a type field rather than a length field, on the protocol running atop Ethernet having a valid length field, so it knows how much of the packet is either trailer or FCS. The packet in question has a length value of 36816 bytes, which means it appears that every single octet of what remains in the packet after the Ethernet header is packet data, not trailer or FCS.

In theory, "eth.assume_fcs: TRUE" should cause Wireshark to treat the last 4 octets of the frame as an FCS, but it doesn't, in fact, do so. I'll look at that bug.

answered 12 Sep '11, 23:29

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

The FCS handling was broken when the Ethernet dissector was changed to parse VLAN headers itself; I've checked in a fix for that in the trunk, and will schedule the fix to go into 1.6.3.

(13 Sep '11, 14:18) Guy Harris ♦♦

It looks like the Ethernet dissector and VLAN headers will be split again as it seems to have caused more problems than it solved. See bug 5680. In light of this, maybe the FCS handling fix shouldn't be scheduled for backporting just yet as it might become obsolete if the two are split up again?

(16 Sep '11, 20:08) cmaynard ♦♦

Backporting the FCS fix fixes a bug if we don't undo the VLAN change, and might make backporting the undo easier if we do undo the VLAN change (backporting undo-the-VLAN-change might require manual intervention if we don't first backport the FCS fix).

(17 Sep '11, 12:28) Guy Harris ♦♦