This isn't my day !!
I also indicated the timeunit incorrectly in my original and first
corrected posting. The correct value is 1,250,000 (1 divided by .8 since 1
tick = .8 usec))
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.
(>>Following corrected from original post<<)
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] = >>1250000<<) in the .cap files I have.
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 >>1250000<< 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
------- End of forwarded message -------