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 "):
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
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.
asked 12 Sep '11, 11:41 steved edited 12 Sep '11, 23:38 helloworld |
One Answer:
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 Harris ♦♦ |
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.
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?
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).