https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14592

            Bug ID: 14592
           Summary: Frame check sequence: 0x00000000 incorrect on short
                    packets from one device
           Product: Wireshark
           Version: 2.4.6
          Hardware: x86-64
                OS: Windows 10
            Status: UNCONFIRMED
          Severity: Normal
          Priority: Low
         Component: Dissection engine (libwireshark)
          Assignee: bugzilla-ad...@wireshark.org
          Reporter: lo...@pacific.net
  Target Milestone: ---

Created attachment 16253
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=16253&action=edit
Short and longer packets from the only device showing the problem

Build Information:
Version 2.4.6 (v2.4.6-0-ge2f395aa12)

Copyright 1998-2018 Gerald Combs <ger...@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
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 Qt 5.6.3, with WinPcap (4_1_3), with GLib 2.42.0, with
zlib 1.2.8, with SMI 0.4.8, with c-ares 1.12.0, with Lua 5.2.4, with GnuTLS
3.4.11, with Gcrypt 1.7.6, with MIT Kerberos, with GeoIP, with nghttp2 1.14.0,
with LZ4, with Snappy, with libxml2 2.9.4, with QtMultimedia, with AirPcap,
with
SBC, with SpanDSP.

Running on 64-bit Windows 10, build 16299, with Intel(R) Core(TM) i7-6600U CPU
@
2.60GHz (with SSE4.2), with 8117 MB of physical memory, with locale
English_United States.1252, with WinPcap version 4.1.3 (packet.dll version
4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), with
GnuTLS 3.4.11, with Gcrypt 1.7.6, without AirPcap.

Built using Microsoft Visual C++ 14.0 build 24215

--
I'm pretty sure this is a minor glitch, after searching a bit. But it was
certainly a distraction from my real problem...  All short (<~70 byte) packets
_from_ one device out of several on a Wi-Fi linked network are showing the
error "Frame check sequence: 0x00000000 incorrect..."  

I was testing short ModbusTCP messages so it looked like all packets, but with
more testing it is clearly size that matters. I found these:

<https://communities-gbot.vmware.com/thread/426699>
-----
Wireshark assumes that an ARP which exceeds 60 bytes must include an FCS,
performs the FCS calculation on the last four bytes, and fails of course.

The second thing will be to take a look at your Wireshark preferences. From the
menu, select Edit -> Preferences, expand the Protocols section, scroll down to
Ethernet and check the setting of the Assume Packets have FCS. If this is
checked, Wireshark will do exactly as it says i.e., assume the packet has an
FCS, and will give you the incorrect FCS error message you're seeing.
-----
--> Mine is NOT checked

<https://osqa-ask.wireshark.org/questions/54651/ethernet-frame-check-sequence-incorrect?
-----
Wireshark's code to try to detect the presence of an Ethernet FCS might not be
working. Please file a bug on this at the Wireshark Bugzilla, attaching, if you
can, a small capture that shows it - one frame would be sufficient.
-----

So since you asked...

-- 
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via:    Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
             mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

Reply via email to