Guy,
I think I found at least one of the problems with interpreting
Sniffer-format files' timestamps:
From what I can tell, setting a value for xxb[20] (from the netxray_hdr
structure in netxray.c) seems to instruct Sniffer to interpret the
timestamps differently. Ethereal doesn't currently check the value of
this field.
Setting it to a value of 0x2, which I see in nearly all traces I have
that were taken with a gigabit ethernet sniffer, seems to cause Sniffer
to divide the timestamps by 1000.
I've noticed that if I set this value for this field in traces that
weren't originally set this way, I also see the timestamp-shifting
behavior when Sniffer reads the files.
So far I've found this to be true in Sniffer Pro 3.5, 4.5, and 4.7.5SP1
(4.7.534), Sniffer Basic 4.5, and Sniffer Distributed 4.10.05, so I'm
assuming this behavior is standard.
I've also noticed that setting this value to something other than 2
seems to cause Sniffer to not display A and B channel information on
gigabit-taken traces, so I'm guessing that this field may somehow
indicate the capture type (i.e. this trace was taken with a "high-speed
module", or something like that). However, I've only seen "special"
behavior (i.e. displaying channel information, shifting timestamps, etc)
with this value set to 2, so far.
Having Ethereal check for this value and shift timestamps appropriately
has fixed timestamp display in many of my captures, and so far I haven't
seen any new problems as a result. There are certainly other problems
(some of which relate to the "timeunit" field, I believe...I'll post a
message if I find anything useful), but I think this is one of the more
common ones.
Ian
On Tue, Sep 17, 2002 at 04:12:18PM -0500, Tobin Schuster wrote:
I have noticed that Ethereal incorrectly displays the packet time when
displaying packets captured using Network Associates Sniffer Basic
version 3.50.02.
We have found that sometimes it displays the packet time correctly and
sometimes it doesn't.
We have also found that if we change the code to correctly display the
packet times for captures where it doesn't display them correctly, it
displays them incorrectly for other captures, so that doesn't count as a
"fix".
The capture format used by the Windows-based Sniffer software isn't
documented anywhere I know of, so it had to be reverse-engineered. It
appears that there is something strange going on with its time stamps,
which we have been unable to determine - although there have been
messages in the past to one of the Ethereal lists claiming that a trace
from either Sniffer Basic or Sniffer Pro on one PC gave the wrong time
stamps when read by Sniffer on another PC, so perhaps the problem is
completely insoluble (if Network Associates can't make it work, it's not
clear that we can make it work).
