This is our old Q&A Site. Please post any new questions and answers at


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

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

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

permanent link

answered 14 Dec '12, 07:54

Bill%20Meier's gravatar image

Bill Meier ♦♦
accept rate: 17%

edited 14 Dec '12, 08:25

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)?


permanent link

answered 15 Dec '12, 13:18

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
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


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 ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 13 Dec '12, 14:19

question was seen: 4,133 times

last updated: 15 Dec '12, 15:58

p​o​w​e​r​e​d by O​S​Q​A