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

tshark linux timestamp strangeness

0

I've run tshark on a linux VM, capturing packets between the linux server and a database server. I've told tshark to use the -t ad option for timestamps and to run for an hour and just redirect it's output to a text file.

The weirdness is that the timestamps in the output file start to drift from the system time (checked by doing a tail on the output file) and tshark finally completes after 90 minutes (despite the log file only having 60 minutes of data logged).

in other words I kicked tshark off at 12.01, and at 13.25 I tailed the output file and the last timestamp in the log was 2015-01-22 13:00:45.715033. When tshark finally completes at 13.31 the last timestamp in the file is 2015-01-22 13:01:58.374895.

I've done exactly the same thing on a server in a different environment and it completes on time (ie after 60 minutes) having logged 60 minutes of data....

Help!

asked 22 Jan '15, 05:00

ecrowe's gravatar image

ecrowe
6112
accept rate: 0%


One Answer:

0

How well do you keep time in your VM? Does it have a 'direct' link from the VM to the host (sometimes certain tools are required IIRC), or does it have a NTP daemon?

answered 22 Jan '15, 05:51

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

It has vmware tools installed, ntpd isn't running.

Just to be clear, the time on the VM itself stays accurate, the times recorded by tshark drift further and further out over time.

(22 Jan '15, 07:03) ecrowe

The times recorded by tshark come from the capture file written by dumpcap, the times in the capture file written by dumpcap come from libpcap, and the time stamps from libpcap come from the Linux kernel's PF_PACKET code, and "the system time" also comes from the kernel, so the two clocks shouldn't drift - they shouldn't even be two clocks.

(22 Jan '15, 16:09) Guy Harris ♦♦

so is it possibly that the time stamps aren't drifting, just that there is some weird delay in writing to standard out / the file?

(23 Jan '15, 03:01) ecrowe

Well, there's a delay with any program writing lines with the C standard I/O library, as it buffers output and only writes to the file every 4096 or so bytes. You can force TShark (or tcpdump) to write the buffer out after every packet by specifying the -l flag.

When you say "tshark finally completes after 90 minutes", what does "completes" mean? Did you tell tshark to capture for 90 minutes, so that it stops on its own, or did you ^C it after 90 minutes, or did you tell it to stop after a certain number of packets were captured?

Were you capturing with a capture filter?

How many packets did it capture per unit of time - was it a high rate or a lwo rate?

When it stopped, did it report any packets being dropped?

(23 Jan '15, 11:28) Guy Harris ♦♦

I told it to do -a duration 3600. despite this it took 90 minutes before it finished.

(26 Jan '15, 02:26) ecrowe