Wireshark-bugs: [Wireshark-bugs] [Bug 9314] New: openSAFETY: Fixing rare crash as well as dissec

Date: Mon, 21 Oct 2013 15:39:17 +0000
Bug ID 9314
Summary openSAFETY: Fixing rare crash as well as dissector errors
Classification Unclassified
Product Wireshark
Version 1.11.x (Experimental)
Hardware x86
OS All
Status UNCONFIRMED
Severity Major
Priority Low
Component Dissection engine (libwireshark)
Assignee [email protected]
Reporter [email protected]

Created attachment 11849 [details]
openSAFETY: Fixing rare crash as well as dissector errors

Build Information:
TShark 1.11.1 (SVN Rev 52729 from master)

Copyright 1998-2013 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 GLib 2.36.0, with libpcap, with libz 1.2.7, with POSIX
capabilities (Linux), without libnl, with SMI 0.4.8, with c-ares 1.9.1, with
Lua
5.1, without Python, with GnuTLS 2.12.23, with Gcrypt 1.5.0, with MIT Kerberos,
with GeoIP.

Running on Linux 3.8.0-29-generic, with locale de_DE.UTF-8, with libpcap
version
1.3.0, with libz 1.2.7.
Intel(R) Core(TM)2 Quad CPU    Q8400  @ 2.66GHz

Built using gcc 4.7.3.

--
In packages where a larger amount of openSAFETY frames is being transported,
the heuristic dissection sometimes misses starting positions of frames. The
result being, that the ADDR field of the openSAFETY frame gets mistaken for the
ID field, resulting in the ID field being the length field. One of the checks
in the dissector tries to read out the bytes of the frame for CRC calculation,
and this will lead to a malformed packet and crash of the dissector engine (no
further sub-packages in this specific frame will be dissected).

Fixing that lead to another error, where the old check for SoC and SoA in the
heuristic search led to false negatives. The check has been removed, as it is
done already in the powerlink entry function for the openSAFETY dissector.

Finally, when frame2 can be dissected (SCM UDID is valid), and it is
determined, that both ID fields differ, the packet is tagged with a protocol
error.

(ct calculation got moved, due to a patch in the future, and to put it closer
to the output of the result of ct)


You are receiving this mail because:
  • You are watching all bug changes.