Wireshark-bugs: [Wireshark-bugs] [Bug 9931] New: Encapsulated ethernet packets sometimes show in
| Bug ID |
9931
|
| Summary |
Encapsulated ethernet packets sometimes show invalid FCS
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.11.x (Experimental)
|
| Hardware |
x86
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Wireshark
|
| Assignee |
bugzilla-admin@wireshark.org
|
| Reporter |
hadrielk@yahoo.com
|
Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
When dissecting Ethernet packets that are within some other protocol, the GUI
sometimes displays "ETHERNET FRAME CHECK SEQUENCE INCORRECT". But this will
only show up in the packet list pane not in the details pane. This is not
easily reproducible (for reasons explained later), and will likely only happen
if (1) the packet came from Lua-based dissector code calling ethernet's
dissector, or possibly (2) in C-code if the Ethernet packet was within ATM
cells, or one of several other protocols (also explained later). And due to
the root cause, my guess is this type of thing might happen for other
link-layer protocols that use pseudo-headers but are encapsulated in another
packet.
The root causes:
1) Several places in the code base use a wtap_pkthdr struct without
initializing it. One of those places happens to be
packet_list_dissect_and_cache_record() in ui/gtk/packet_list_store.c, which
gets called to display the packet list. It calls cf_read_frame_r() with this
uninitialized phdr, and cf_read_frame_r() then calls the file format reader
seek_read routine. If the file format reader doesn't reset the pseudo-header,
then by the time Ethernet gets the packet the pseudo-header will be random
garbage. This code isn't the only culprit, BTW... lots of code doesn't
properly initialize the wtap_pkthdr.
2) Even if the file reader had set the pseudo-header, if the lower link-layer
encap wasn't Ethernet but something else like ATM, it would set the
ATM-specific pseudo-header info. But when the ATM cells contain an Ethernet
packet inside, ATM's dissector doesn't call the dissector for "eth_withoutfcs"
or "eth_withfcs", which I believe it should do, but instead calls the basic one
for "eth", which then uses the pseudo-header as an Ethernet one. And ATM isn't
the only one that does this either... quite a few others do as well.
p.s. It took me a looong time to figure this out, mostly because I missed some
obvious clues; but also because it was hard to reproduce since the
uninitialized struct happens to contain 0's in the pseudo-header frequently.
You are receiving this mail because:
- You are watching all bug changes.
