Ethereal-dev: [Ethereal-dev] netxray 'Timeunit' issues: help requested

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Bill Meier" <wmeier@xxxxxxxxxxx>
Date: Sun, 21 Nov 2004 22:12:15 -0500
I've now spent some time reading thru the mailing lists about sniffer capture
files and 'timeunit' determination. I see that there's been much good effort
expended and that I've been somewhat naïve about being able to arrive at the
'right' answer. :(

Be that as it may:

I've spent some time determining the reasons Ethereal 0.10.7 displays times
incorrectly on my PC for certain NDIS sniffer captures of varying formats
that I have.

I've found 3 problems with respect to decoding times for v2 format files.

The apparent changes for two of the problems conflict with previous work done
with respect to determining 'timeunit'.

In each of the two cases there are comments in the code as to 'captures
having been seen' having certain values for 'CAPTYPE" and 'TIMEUNIT' and
indicating that the  timeunit should be such and such for same.

However, I have capture files with the same header values for 'CAPTYPE' and
'TIMEUNIT' which require a different actual timeunit value to decode
correctly.

(I'm obviously encountering the same ambiguities and conflicts in determining
timeunit as reported by previous posters).


I'm happy to make an attempt to move the ball forward on the issue of
'timeunit' determination and correct time display for sniffer capture files.
(I've seen the comments about "different times for the same file on different
PC's"; I'd still like to give this a try).

(This is worth some energy on my part because it's a pain to have to keep a
customized version of Ethereal which displays *my* sniffer capture files
correctly).

So: I would appreciate it if anyone can provide a copy of (or a pointer to)
certain captures used in previous work on sniffer capture file decodes as
well as an indication of the correct time ('arrive time' for the first
packet).  I will then see if I can make any headway. (A hex dump for the
first 1K bytes of the captures or so is a second choice).

I'm specifically interested in captures related to two cases as follows:

1.   [Comment from code]
		 * It also appears that the time units might differ
		 * for gigabit pod captures between version 002.001
		 * and 002.002.

    I've v2.002 gigabit pod captures which appear to need the same timeunit (for
    hdr.timeunit=2) as for v2.001 [that is: 3125000].


2. [Comments from the SVN source tree]

    Revision 7388  - [...]
    Mar 31 21:11:49 2003 UTC (19 months, 3 weeks ago) by guy
    [...]
    The units, in non-whizzo-gigabit-pod captures, for hdr.timeunit = 2 aren't
    1/1193000.0 second; the code used to use 1/1193180.0 second, but at
    least one capture appears to have units of somewhere around 1/3579540.0
    second.

===> Captures I have for this case need a timeunit of 1193180.


    Revision 7380  - [...]
    Mar 28 21:59:12 2003 UTC (19 months, 3 weeks ago) by guy File length:
    [...]

    Ian Schorr discovered that, for gigabit pod captures, if hdr.timeunit
    is 2 the time stamps are in units of 1/31250000 seconds rather than
    nanoseconds - and, by generating Windows Sniffer captures with various
    hdr.timeunit values, that for all the non-zero values he tested, the
    time stamps for non-gigabit pod captures are in units of 1/1193000
    second.

==============================================================================
===========

For what it's worth, the following is what I've found so far for captures
that I have:

  version  hdr.xxb[20]  hdr.timeunit   correct     ignore hdr      Capture
Type
            [CAPTYPE]                 "timeunit"  timehi/timelo ?
  =======  ===========  ============  =========   ============
======================
    2.1       0                0       1000000     No             = "NDIS"
    2.2       0                0       1000000     No             = "NDIS"
    2.2       0                2       1193180     No             = "NDIS"
    2.2       2                2       3125000     YES            = "Gigabit
Pod"
    2.2       3                0       1000000     No             = "PPP
Captured with Pod"
    2.2       3                2       1250000     YES            = "PPP
captured with Pod"



Thanks

Bill Meier