| 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.