Wireshark-bugs: [Wireshark-bugs] [Bug 3473] Ethernet dissector passes FCS to sub-dissectors
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Wed, 20 May 2009 14:57:09 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3473


Guy Harris <guy@xxxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|VLAN dissector passes FCS to|Ethernet dissector passes
                   |sub-dissectors              |FCS to sub-dissectors




--- Comment #5 from Guy Harris <guy@xxxxxxxxxxxx>  2009-05-20 14:57:09 PDT ---
"According to IEEE Std 802.1Q, 4-byte FCS always present at the end of VLAN
frame."

And according to IEEE Std 802.3, a 4-byte FCS is always present at the end of
an Ethernet frame.  However, the hardware and drivers don't always present the
FCS to the host, so there's no guarantee that the FCS will always be present in
Ethernet packets in a capture file - and, unfortunately:

    1) there's no mechanism in any existing capture mechanism to indicate
whether the FCS is present in an Ethernet frame

and

    2) if you're capturing outgoing as well as incoming packets, even if the
hardware and drivers *do* present the FCS to the host, not all frames will have
it, as outgoing frames won't (they're passed to the capture mechanism before
they're provided to the Ethernet adapter)

hence the heuristics, which work for

    1) 802.2 frames, where there's a length field in the 802.3 header

and

    2) Ethernet frames where the transported protocol has a length field of its
own, e.g. IPv4 and IPv6, so that the dissector can determine whether there's
anything past the end of the payload, and attempt to determine how much of that
is trailer and how much of it is FCS.

So the problem is, ultimately, not that the VLAN dissector needs an option to
tell it whether the frame has an FCS or not, the problem is that the Ethernet
dissector needs such an option.  The VLAN dissector needs to propagate any
changes to the payload tvbuff length to its tvbuff length, and to leave the
trailer/FCS processing to the Ethernet dissector, rather than calling
ethertype().


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