https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4256
Summary: Timestamp negative offset
Product: Wireshark
Version: 1.2.4
Platform: x86
OS/Version: Windows Server 2003
Status: NEW
Severity: Minor
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: dannybeutler@xxxxxxxxx
Created an attachment (id=3984)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=3984)
Timestamps out of order
Build Information:
Version 1.3.1 (SVN Rev 30724 from /trunk)
Copyright 1998-2009 Gerald Combs <gerald@xxxxxxxxxxxxx> 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 with GTK+ 2.16.6, with GLib 2.22.2, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8,
with c-ares 1.6.0, with Lua 5.1, without Python, with GnuTLS 2.8.1, with Gcrypt
1.4.4, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Oct 26
2009), with AirPcap, with new_packet_list.
Running on Windows Server 2003 Service Pack 2, build 3790, with WinPcap version
4.1.1 (packet.dll version 4.1.0.1753), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.8.1, Gcrypt 1.4.4, 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.
--
Packet timestamps are incorrect. As you can see in the attached sniff, the
offset from the previous packet is negative for some packets. I am going to
refer to the attached sniff as I explain this so it may help to have it open as
you read this.
Packet #3 shows a negative offset of .723821 seconds from the previous packet.
Packet #4 shows a positive offset of .734627 from the previous packet. It
seems as if there is a clock which is behind by about .73 seconds which some of
the packets (#3,6,13,20,35,44,etc.) are getting their timestamp from. The
interesting thing is that this .73 second gap widens with system uptime. For
instance, immediately after rebooting the server, the gap was only .007
seconds. Now that the system has been up for a few days the gap is .73
seconds. When I first noticed the problem the server had been powered on for
over a month and the gap was at 12 seconds. Needless to say, this makes
reading the packet capture and calculating response times very difficult.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
