Ethereal-dev: Re: [Ethereal-dev] patch to fix time display in sniffer pro capture files
> I was comparing delta packet times between the same capture
> file displayed by ethereal 0.8.17 and Network Associates
> Sniffer Distributed Pro V4.0.08, and found a consistant
> discrepency. The attached patch to wiretap/netxray.c
> corrects the problem.
>
> I assume the old value for timeunit exists for a reason.
> Perhaps some older version of netxray created files using
> it. The current Network Associates product uses the value
> 1000000.0, though.
Some versions of the Network Associates software *did*, in fact, use
1193180.0; this was discussed in some earlier mail - look in the
February 2001 ethereal-dev archives:
http://www.ethereal.com/lists/ethereal-dev/200102/
for the messages with "NetXray / Sniffer Time Codes" in the subject.
In case you're curious "why 1193180.0", then, from one of those
messages:
From my copy of "ISA System Architecture", a manual describing
PC/AT-compatible PCs (i.e., PCs prior to EISA, Microchannel,
VESA Local Bus, and PCI):
Chapter 24
Prior To This Chapter
The previous chapter described the numeric coprocessor
interface and floating-point emulation.
In This Chaper
This chapter describes the system timers incorporated in
all ISA-compatible machines.
-------------------------------------------------------------------
The System Timer, Timer 0
The System Timer, Timer 0, is a programmable frequency
source. A 1.19318MHz signal provides its input clock
rate. You can specify a divisor to divide into the
input clock to yield the desired output frequency. ...
1/(1.19318*10^6) = .838096*10^-6, i.e. 1.19318 MHz is one cycle every
.838096 microseconds.
The classic Sniffer was a notebook PC with Network General's
software running on top of DOS, but "running on top of DOS"
doesn't prevent you from whacking the PC system timer to keep
whatever time you want, including setting the divisor to 1.
I seem to remember reading some Sniffer documentation that
(partially) described the classic Sniffer file format; I think it
gave the various time unit code values as
0 Unspecified - default by network type
1 "PC" - 0.838096 microseconds
2 "3Com" - 15 microseconds
3 "Micom" - 0.5 microseconds
4 "Sytek" - 2 microseconds
I suspect that "PC" means "we used the PC's timer to time-stamp
packets", and that "3Com", "Micom", and "Sytek" refer to using a
timer on network interfaces from the company in question to
time-stamp packets.
> Other than cussedness? Seems goofy
> that NG would force the use of floating point into something
> as basic and pervasive as measuring time.
Blame IBM, or maybe Intel, depending on who specified the system
timer input signal frequency. :-)
I guess at least some versions of the Windows version of the Sniffer
software adopted, after the acquisition of Cinco Networks (the makers of
NetXRay) by Network Associates (the result of the merger of Network
General, the makers of Sniffers, and McAfee Associates; I guess "McAfee
General" would have sounded too much like a hospital), picked up the
PC-timer time stamp from the DOS Sniffer software (the original NetXRay
used 1-millisecond units, and a later version of the software, from
Network Associates, appeared to use 1-microsecond units).
The original mail from that thread said:
One of my clients makes heavy use of NAI's Distributed Sniffers.
I'm working with them to debug problems they see with some web-based
apps they've written. They've given me some traces in .cap format,
which appear to be NetXray version 2.001 files. I use ethereal to
dig through these traces, and I use tethereal to get timings using
awk/perl/whatever.
...
After some digging around in wiretap/netxray.c and staring at
the differences in times displayed by all three tools for the
different formats, I've concluded that a tick in a .cap file
is not a micro-second. Instead, a tick is 88/105ths of a
micro-second, or thereabouts.
(88/105ths of a microsecond are, approximately, the units of the PC
timer.)
Later mail contained a file with a version of 2.002, which appears to
have different units, at least as I read the message.
What's the version number in the captures you saw? Perhaps either
1) different versions have different time stamps
or
2) there's some header-file field that indicates the version
but there was at least one capture with a version of 2.001 and units of
1/1193180 of a second, so just going back to 1/1000000 of a second, as
per your patch, would be wrong.
I'm CC'ing the folks in the thread back in February, in case they're not
currently on ethereal-dev.
