https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6703
Summary: ZEP dissector: Timestamp not always displayed
correctly. Fractional seconds never displayed.
Product: Wireshark
Version: 1.6.2
Platform: x86
OS/Version: Windows 7
Status: NEW
Severity: Normal
Priority: Medium
Component: Wireshark
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: honarbacht@xxxxxxxxx
Created an attachment (id=7631)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=7631)
Two ZIP compressed capture files with ZEPv2 frames covering the two timestamp
display bugs
Build Information:
Version 1.6.2 (SVN Rev 38931 from /trunk-1.6)
Compiled (32-bit) with GTK+ 2.22.1, with GLib 2.26.1, with WinPcap (version
unknown), with libz 1.2.5, without POSIX capabilities, without libpcre, with
SMI
0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS 2.10.3,
with
Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built
Sep
7 2011), 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.10.3, Gcrypt 1.4.6, without AirPcap.
Built using Microsoft Visual C++ 9.0 build 21022
--
The dissector for ZigBee Encapsulation Protocol does not always display
timestamps correctly. The timestamp is in standard NTP format, i.e. 64-bit
unsigned fixed point (Q32, i.e. 32.32) couting seconds since Jan 1, 1900.
There are two issues here:
1) Fractions are not taken into account at all, i.e. fractions always show as
".000...s".
For in-depth 802.15.4 wireless protocol stack analysis a resolution of at least
16 microseconds is required (2.4GHz physical layer symbol rate). The capture
hardware being used ("ubisys IEEE 802.15.4 Wireshark USB Stick") provides this
accuracy using an on-board timer/counter.
Attached is a capture file with a number of frames with NTP timestamps. The
binary view shows non-zero fractions correctly. Notice that for this capture
timestamps should be considered relative. The clock always starts Jan 1, 2012
when the capture device is plugged in and the IEEE 802.15.4 symbol timer starts
to increment its count. This is a work-around for the second bug mentioned
below.
2) Certain time-stamps are displayed as "not representable". Timestamps in the
Jan 1 1900 + "a number of seconds" region are displayed as "not representable"
and their absolute value is displayed incorrectly. The second attached capture
file contains a number of packets captured this way. Instead of 0x000000c9 ->
201.xxxxs = Jan 1, 1900, 00:03:21 (expected result), Wireshark states "Not
representable (2085978697.000...0s)". Adding 0xd2aa2080 (Jan 1, 2012, see
above) to the integer part in the capture device resolves the problem.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
