ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 6260] Saving ERF files.

Date: Thu, 1 Sep 2011 23:45:44 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6260

--- Comment #13 from Guy Harris <guy@xxxxxxxxxxxx> 2011-09-01 23:45:41 PDT ---
> I presume the ETH dissector should be detecting and displaying it as a FCS/CRC rather than a trailer. Perhaps it should have a 'verify FCS' preference/expert infos as well similar to other protocol checksum checking?

Not only should it be doing so, it is doing so.  If the Wiretap module says
"there's an FCS" it assumes the last 4 octets of the packet (the packet, not
the captured part of the packet) are an FCS, and checks it.  If the Wiretap
module says "there's no FCS" it assumes there's no FCS.  Otherwise, it tries to
guess, based on the frame length and the purported packet length (based on the
length field if present, otherwise based on whatever the protocol running on
top of Ethernet sets the length to, e.g. IPv4 and IPv6 set it based on the
total datagram length), whether there's an FCS or not.

It has no preference to disable FCS checking - if it thinks there's an FCS, it
will check it - and it currently adds no expert info if the FCS check fails.

For Ethernet traces where it's known that there is, or isn't, an FCS
(everything except for some DOS Sniffer files, all pcap and most if not all
pcap-ng files, RADCOM files, Toshiba ISDN router logs, and Visual Networks
capture files), the ERF file writing code can skip generating the FCS if the
eth.fcs_len field of the pseudo-header is 4, as that means the packet has an
FCS.  If it's 0, the packet definitely doesn't have an FCS; -1 means we don't
know.  The heuristics are done at the dissector level, so the result isn't
available to code at the Wiretap level; it *might* be possible to duplicate
some of the checks at that level, but I don't know whether it'd always get it
right.  (Packets with a length field are easier than packets with a type field.
 I think one case where we *cannot* get the right answer are Spanning Tree
Protocol packets, which have a type field and no length field in STP.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.