Ethereal-users: [Ethereal-users] Re: Network Associates Sniffer timestamps displayed incorrectly

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Bill Meier" <wmeier@xxxxxxxxxxx>
Date: Thu, 03 Jul 2003 10:37:03 -0500
I see that I misspoke slightly when I sent this last night. The fields in 
the .cap file header with apparent garbage were 'timelo' and 'timehi' 
(*not* 'start_time'). (I've corrected my statements below).


>> I am using a Network Associates Sniffer with software Distributed Pro
>> Version 4.20.033.  I am using Ethereal version 0.9.13.
>>
>> The timestamps are displayed as follows:
>> On Sniffer software 7/1/03 2:06:23 PM
>> On Ethereal         7/1/03 13:58:24.-311130
>>
>> I tried using editcap -F ngwsniffer_2_0 sniffer_file.cap
>> sniffer_file.pcap
>> and it changed the time shown in Ethereal to 7/1/03 10:43:53.-357631
>>
>> Is there any way to convert the timestamps?

>The only way to do that would be to:
>
>	find out why, in that particular capture, the time stamps are coming 
>out wrong;
>
>	fix it in such a way as not to break the interpretation of any *other* 
>Sniffer files.

  <snip>


I encountered the exact same problem several weeks ago. Finding that no one 

else seemed to have a solution I downloaded the source and did some 
debugging to see what's going on.

It turns out that a newer version of the sniffer (v4.10.? v4.20 ? which 
shows 002.002 as the version in the .cap file header) uses a tick of .8 
usecs (Tps [Ticks per second] = 1125000) in the .cap files I have. 

(>>Following corrected from original post<<)
It also appears to be the case that the >>"timelo" and "timehi" fields<< in 
the file header contain garbage. 

I was able to get the correct output from Ethereal (matching that from the 
sniffer) by adding code to netxray.c to use 1125000 as the 'timeunit' and 
by ignoring the value in the file header >>"timelo" and "timehi"<< fields 
(i.e.: using 0 as the value for these fields).
(>><<)

I've been busy and have been  meaning to provide examples of the headers, 
etc so that someone more familiar with the different variants can best 
determine how to add this variant so as to "fix it in a way as not to break 
the interpretation of any *other* Sniffer files".

I will provide debug print-outs of file and data record headers from 'old' 
(working) and 'new' (bad time time-dsiplay) sniffer captures in the next 
day or so.

Bill Meier