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 |
[email protected]
|
Reporter |
[email protected]
|
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 <[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 (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.