Wireshark-bugs: [Wireshark-bugs] [Bug 6703] New: ZEP dissector: Timestamp not always displayed c
Date: Fri, 30 Dec 2011 02:00:30 -0800 (PST)
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.
- Prev by Date: [Wireshark-bugs] [Bug 6702] Patch to support latest GTK+ MAC OS X integration
- Next by Date: [Wireshark-bugs] [Bug 5531] add support for ANSI C12.22 protocol
- Previous by thread: [Wireshark-bugs] [Bug 6702] Patch to support latest GTK+ MAC OS X integration
- Next by thread: [Wireshark-bugs] [Bug 5531] add support for ANSI C12.22 protocol
- Index(es):