| Bug ID |
9933
|
| Summary |
Questionable calling of ethernet dissector by encapsulating protocol dissectors
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.11.x (Experimental)
|
| Hardware |
x86
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Minor
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
This is based on Bug 9931. Part of that bug had to do with encapsulated
Ethernet packets showing invalid FCS because the Ethernet packet is
encapsulated inside some lower link-layer with a different pseudo-header.
I believe the intent is for encapsulating dissectors to not call the "eth"
dissector handle in such cases, but instead to call either the one for
"eth_withoutfcs" or "eth_withfcs", because just plain "eth" is the
dissect_eth_maybefcs() code which looks in the pseudo-header, assuming that
it's an ethernet pseudo-header; and if finds a fcs number > 0, it will process
it as such.
The following dissectors call the "eth" one currently:
1) ATM AAL5 in packet-atm.c - this one's hard to fix because it's not
LLC-encapsulated ATM AAL5, so it's not defined if it's with or without an FCS;
instead that's a per-VC decision. (see RFC 2684)
2) The B.A.T.M.A.N. dissectors, in packet-batadv.c: I have no idea what this
protocol is.
3) The Arbor Networks E100 packet encapsulation dissector, in packet-e100.c. I
don't know whether their packet encap has the original FCS or not.
4) Ethernet over Infiniband (EoIB) does it, but I believe there is no Ethernet
FCS/CRC when encap'ed over Infiniband. There's just the Infiniband CRC after
the Ethernet header and payload.
5) TRILL (TRansparent Interconnection of Lots of Links) does it, but it's not
clear if it should. If there is an Ethernet FCS, it will be for the outer
TRILL packet, not for the encapsulated Ethernet packet. (see RFC 6325)
6) Virtual eXtensible Local Area Network (VXLAN) does it, and again like TRILL
it's not clear if it should, because the encapsulated Ethernet apcket doesn't
have an FCS, and the outer one's FCS applies to the whole packet not the inner
one.
Since I don't know what should happen with the above cases, and don't have
capture files with them, I'm not fixing it. :)
You are receiving this mail because:
- You are watching all bug changes.