Ethereal-dev: Re: [ethereal-dev] Re: [ethereal-users] Problem with Absolute Date Function, plu
OK, let's try this again (the joys of a mailer where hitting a single
letter key by accident sends a message):
On Mon, Jul 17, 2000 at 06:13:03PM -0700, Guy Harris wrote:
> There is, I suspect, something wrong with the time-stamp reading code
> for Sniffer-format files in both the version of Network Monitor I have
> here *and* in the Wiretap library used by Ethereal/Tethereal/editcap. I
> shall have to see what the time stamps are in the two ".trc" files, and
> see why Wiretap is concluding they are what they are.
Well, the code in Wiretap for sniffer files ignores the time value in
the file header; there's a comment saying
/* The time does not appear to act as an offset; only the date
commenting out the code that looks at them.
This *might* have been derived from some code in a modified version of
libpcap I have that reads Sniffer files; the comment there was
/*
* XXX - it appears that the time stamps are times *since the
* beginning of the day the capture was started*, not since
* the second the capture was started.
*/
That looks like the sort of comment I'd write, and the code in tcpview,
from which I derived the libpcap code, didn't bother to look at the time
and date values in the file header *at all*, it just used the per-packet
time stamps (which doesn't work at all), so I *presume* there was some
file where it *appeared* that the per-packet time stamps were relative
to the beginning of the day the capture was started.
However, it may be that I was testing the code by checking to see
whether the version of Network Monitor I had at the time reported the
same time stamps that the program in question (a hacked-up version of
tcpview on which I was working before I discovered Ethereal) did; if
NetMon wasn't handling dates/times in Sniffer files correctly, I may
just have been reproducing its buggy behavior....
If I make Wiretap use the time value in the file header, the time stamps
I get from "OAE.trc" start with 01:01:52.5723, which is closer to the
01:01:39.876 that NetMon got on "netmon.cap" than is the 00:00:08.5723
that current Ethereal gets - and is also closer than the 00:02:48.037
that NetMon got for you. The delta between the NetMon time stamp and
the modified-Wiretap Ethereal time stamp from the Sniffer-format file
(both of which are, I think, in local time in the files, so I suspect it
may not be a time zone problem) may just be a difference between the
clocks in the machines on which the captures were made, if they were
done on different machines.
Can you get your Sniffer back (assuming it's a DOS-based classic
Sniffer, not one of those new-fangled Windows Sniffers, as those use a
different capture file format) and get a capture, and then send me both
the capture file *and* a printed text output from the Sniffer showing
what time *it* thinks the packets have? You might also want to see
whether Network Monitor, when handed that file, gets the same time, a
time that's off by 1 hour (in which case there might be a time zone
problem), or a time that's off by a value that's not a multiple of 1
hour (in which case Network Monitor might, indeed, not be handling
Sniffer files correctly. That may help me figure out whether the
Sniffer-file code really does need to take into account the time in the
file header.
If you can't get the Sniffer back, if anybody else with a DOS-based
Sniffer could do the above, that'd be helpful too.
