> For what it's worth:
>
> 1) 88/105 is about .838;
>
> 2) in Sniffer Classic (".enc") files, the time stamp units are
> specified by a small integer in the version record, and if
> the value of that integer is 1, the time stamp units are
> .838096 microseconds). (See the "Usec" array in
> "wiretap/ngsniffer.c".)
Thanks, I found it about 3 hours after I sent my prev msg.
Just out of curiosity, are there any ideas about why that
value was chosen? Other than cussedness? Seems goofy
that NG would force the use of floating point into something
as basic and pervasive as measuring time.
> Now, whether
>
> 1) NetXRay always used that time stamp value (I don't think it
> did);
>
> 2) Network {General, Associates - I forget whether they bought
> Cinco before or after the NG/McAfee merger} used a different
> time stamp in the Windows sniffers than in NetXRay;
>
> 3) there's a number in the Windows sniffer capture file header
> giving the units, Sniffer Classic-style;
>
> is another matter.
Yup.
Anybody got some true-blue NetXray captures I could
compare to the Sniffer captures I have as I try to sort this
out? The first 60 bytes of header for a 1/2 dozen or so captures
would get me started.
There are 22 bytes in the NetXray header that the current
dissector doesn't understand. Of those, I see 9 bytes that
change across the v2.1 NetXray capture files I have, so those
can't be a timescale selector. If I align the changing values
to 4 bytes where it more or less makes sense, I can eliminate
another 3 bytes from the candidates.
If I just make a wild guess, I'd say it's in the 45th byte after
the magic cookie at the file's start. In the v2.1 caps I have, that
byte has a value of 2, whereas the v1.1 format that ethereal writes
puts a 0 there.
All of which presupposes, perhaps erroneously, that 3) is how it's done.
Chris.
