Wireshark-bugs: [Wireshark-bugs] [Bug 8170] New: Small update to packet-selfm.c for different FM
Date: Mon, 07 Jan 2013 20:12:05 +0000
Bug ID 8170
Summary Small update to packet-selfm.c for different FM Data Types
Classification Unclassified
Product Wireshark
Version 1.9.x (Experimental)
Hardware x86
OS Windows 7
Status UNCONFIRMED
Severity Major
Priority Low
Component Dissection engine (libwireshark)
Assignee bugzilla-admin@wireshark.org
Reporter cbontje@gmail.com

Created attachment 9776 [details]
Update to packet-selfm.c 01/07/2013

Build Information:
Version 1.9.0-SELFM (SVN Rev Unknown from unknown)

Copyright 1998-2013 Gerald Combs <gerald@wireshark.org> 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 (32-bit) with GTK+ 2.24.14, with Cairo 1.10.2, with Pango 1.30.1, with
GLib 2.34.1, with WinPcap (4_1_2), with libz 1.2.5, without POSIX capabilities,
without libnl, with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python,
with GnuTLS 2.12.18, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with
PortAudio V19-devel (built Jan  7 2013), with AirPcap.

Running on 32-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 30729

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
I also added in support for detection/retrieval of 0xa5c2/0xa5c3 and
0xa5d2/0xa5d3 config/data frames, in addition to the previously-support
0xa5c1/0xa5d1 frames.  Little modification was needed either than some
additional function calls for the new frame types and an additional parameter
to the dissect_fmdata_frame function that specifies the type of config frame
that would decode that particular type of data frame.

There is also a correction for a specific data type (FM_CONFIG_ANA_SFTYPE_FPS
-> FM_CONFIG_ANA_SFTYPE_FPD) which it turns out is a double-precision IEEE
Floating Point format value.  Updates were made throughout the code to detect
and process this data type.

I've attached a sample pcap that shows the new frames being detected/decoded
(ignore the duplicate Ethernet frames in the pcap that is a problem with the
capture device currently).

Chris


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