This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Dumpcap timestamp discrepancy

0

Hi,

I am trying to capture packet data to a file using dumpcap script in libpcap format on centos 6.2.

When left the capture script running for an extended period of time (weeks/months) it seems the timestamps recorded in our captures slowly drift backwards. The timestamp recorded in the filename as each new file is created matches the system time relatively well (from observation; i.e. when BAT_99717_20090415222212.cap was created, the system clock showed 10:22 PM.) however the packet timestamps within the file are off by a significant amount. (In this particular example, the first packet in the file has a timestamp of 22:16:18, nearly 6 minutes earlier than when the file was opened.)

Stopping and restarting the service seems to correct this; after a restart, the first packet in the new file had a timestamp closely matching the timestamp in the filename (and the OS time.)

Is there any solution/way anyone knows how I keep the clock that dumpcap used constantly synchronized with the OS time?

Is it a bug?

Please help.

asked 13 Dec '12, 14:19

helloworld0722's gravatar image

helloworld0722
10779
accept rate: 0%

edited 13 Dec '12, 14:31

what is you dumpcap version (dumpcap -v)?

(14 Dec '12, 07:48) Kurt Knochner ♦

it is Dumpcap 1.8.0rc2

(15 Dec '12, 11:31) helloworld0722

2 Answers:

3

See Timestamps drift from real time (applies to Windows)

Update: I just realized that you are using centos (not Windows). So, I don't know if the winpcap timestamp drift issue also applies to libpcap (used on *nix systems).

If you haven't already done so, I suggest searching for something like "libpcap timestamp drift" or "libpcap timestamp"

In any case, Wireshark (dumpcap, etc) just uses the timestamps provided by the capture driver (winpcap, libpcap, etc).

So, this question is better directed to the maintainers of same.

For libpcap: see www.tcpdump.org

answered 14 Dec '12, 07:54

Bill%20Meier's gravatar image

Bill Meier ♦♦
3.2k1850
accept rate: 17%

edited 14 Dec '12, 08:25

0

it is Dumpcap 1.8.0rc2

as I don't have that behaviour on Ubuntu 12.04 with dumpcap 1.8.4, I suggest you try the latest dumpcap release. If you see the problem there as well, we might need some additional information.

  • is your Linux a virtual machine. If so, what is the Hypervisor?
  • how did you start dumpcap (parameters)?
  • Do you use an NTP server? If so, do you see any log entries about "NTP clock skew" (or similiar)?

Regards
Kurt

answered 15 Dec '12, 13:18

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

I am downloading and trying new release 1.8.4. Will let you know the outcome. Thx.

Which libpcap version do you use ? I am using libpcap 1.1.1

Ans. 1) Its not a virtual machine 2) dumpcap is started by providing dumpcap -i eth0 -P -g -s 65536 -w /tmp/test.pcap -b files:100 -b filesize:1000000 -b duration:100 -q -t 3) NTP is in sync. No error found in logs.

(15 Dec '12, 15:14) helloworld0722

Which libpcap version do you use ? I am using libpcap 1.1.1

same.

Will let you know the outcome.

O.K. we will see. Can you please record the time of your machine, just to make sure there are no time jumps caused by a faulty NTP server (I have seen this a few times).

while true; do date >> date.txt; sleep 1; done

Then check date.txt as soon as you see the libpcap 'time jumps' again.

(15 Dec '12, 15:58) Kurt Knochner ♦