Wireshark-bugs: [Wireshark-bugs] [Bug 10457] New: Ethernet FCS with incorrect frame-length
Date: Tue, 09 Sep 2014 12:46:24 +0000
Bug ID | 10457 |
---|---|
Summary | Ethernet FCS with incorrect frame-length |
Product | Wireshark |
Version | 1.12.0 |
Hardware | x86 |
OS | All |
Status | UNCONFIRMED |
Severity | Major |
Priority | Low |
Component | Dissection engine (libwireshark) |
Assignee | [email protected] |
Reporter | [email protected] |
Created attachment 13046 [details] Example Trace with erronous frame #5 Build Information: Version 1.12.0 (v1.12.0-0-g4fab41a from master-1.12) Copyright 1998-2014 Gerald Combs <[email protected]> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled (64-bit) with GTK+ 2.24.23, with Cairo 1.10.2, with Pango 1.34.0, with GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, without Python, with GnuTLS 3.1.22, with Gcrypt 1.6.0, without Kerberos, with GeoIP, with PortAudio V19-devel (built Jul 31 2014), with AirPcap. Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), GnuTLS 3.1.22, Gcrypt 1.6.0, without AirPcap. Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, with 4083MB of physical memory. Built using Microsoft Visual C++ 10.0 build 40219 -- In the accompanying trace, frame #5 displays an error in the frame check sequence, although "Assume packet has FCS" is disabled for ethernet. The frame in itself is wrong, as it should be only 60 Bytes (without the FCS) long, but somewhere on the sender or receiver a frame the size of the MTU was either placed on the net or picked up from there. Two issues with wireshark arise for me with frame #5. First, the "Padding" field for Ethernet displays the correct padding bytes. This happens, because the epl dissector sets the number of dissected bytes with tvb_set_reported_length in packet-epl.c:2451, which together with 14 bytes ethernet header leads to the correct padding length of 28 bytes. But still the frame check sequence does use the last 4 bytes. The issue here is inconsistency. Either the padding uses all available bytes (which would be wrong, but consistent with the FCS), or the FCS uses the correct 4 bytes, which would be wrong with the frame. Second, the display in the byte view pane is wrong, as it displays all the remaining bytes belonging to the epl dissector even if that dissector clearly stated the number of bytes he is used for.
You are receiving this mail because:
- You are watching all bug changes.
- Prev by Date: [Wireshark-bugs] [Bug 10456] "No interface can be used for capturing in this system with the current configuration"
- Next by Date: [Wireshark-bugs] [Bug 10453] When export to a CSV, Info is changed to differ.
- Previous by thread: [Wireshark-bugs] [Bug 10456] ChmodBPF launch daemon not being run by the installer?
- Next by thread: [Wireshark-bugs] [Bug 10458] New: Typo in packet-netflow.c
- Index(es):
- Get Wireshark
- Download
- Code of Conduct