Ethereal-users: [Ethereal-users] RE: netxray.c Time Calculations (file version 2.2)

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

From: "Ken Mann" <KMann@xxxxxxxxxxxxxxx>
Date: Fri, 28 Jan 2005 16:44:55 -0700
 Date: Thu, 27 Jan 2005 17:07:02 -0500
Subject: Re: [Ethereal-users] netxray.c Time Calculations (file
 version 2.2)
To: Ethereal user support <
ethereal-users@xxxxxxxxxxxx>
Message-ID: <
41F96606.3070300@xxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 
Excellent - I was hoping we'd get more folks looking into timetick
values for Sniffer.  I do have a couple of clarification questions so
that I can look at some of my captures:
 
1.  You state that the 64-bit time stamp appears to be output when
Sniffer is told to write the capture buffer to a file.  Does that mean
that if you have sniffer capture to a memory buffer or straight to
"expert" that it doesn't write those timestamps?

[Ken Mann] Yes, I think. I am not familiar with "expert". The capture to file setting I am referring to is on the "buffer" tab when defining a capture filter in the windows environment.
In my environment we have a central "Sniffer" PC and everyone has a license for Sniffer basic on their desktop. We also have a few laptops for wireless sniffs. I am fairly confident in the cause/effect correlation I have seen.
 
 2.  How do you know that the time stamp in each packet is pure micro
seconds when the timehi:timelo is zero (I'm not questioning if you're
correct, just interested in your source of information as I got very
interested in this lately and can't find it documented anywhere).
[Ken Mann] Basically, it is an assumption based on how Sniffer displays time in the decode display. The delta time field (formatted: 0.000.000) yields results like 0.000.134 as 134 micro seconds or 0.014.802 is 14.802 milliseconds. This interpretation is borne out by things like Beacon intervals (100 milli seconds). I have also taken packets out of files with and without timelo and timehi and inserted arbitrary deltas (like 10 milliseconds) and verified that the time change I intended is correctly interpreted by the sniffer software.
 
Thanks!
 
Ken Mann wrote:
> I have found what I believe is a discrepancy in how the time of each
> packet is determined. My experience is limited to version 2.2 with files.
> In the current netxray.c, realtick is read (with appropriate byte
> ordering) into timeunit. Timeunit is used to convert the time stamp of
> each packet into units of seconds. 64-bit time stamp (timehi:timelo)
> appears to be output when Sniffer is told to write the capture buffer to
> a file. In that instance, all the algorithms in the current netxray.c
> (10.9) are correct. However, if timehi:timelo is zero, the time stamp in
> each packet is pure micro seconds and should be divided by 1E6 to
> convert to seconds, NOT the value found in realtick.
> I have also observed that a different value of realtick/timeunit is
> written to the file depending on the type of network (0x1234DE for
> ethernet, 0x369E99 for 802.11)

> struct netxray_hdr {
> ...
>  guint8 timeunit; /* encodes length of a tick */
>  guint8 xxa[3];  /* XXX - is this the upper 3 bytes of the time units? */
>  guint32 timelo;  /* lower 32 bits of time stamp of capture start */
>  guint32 timehi;  /* upper 32 bits of time stamp of capture start */
>  guint32 linespeed; /* speed of network, in bits/second */
>  guint8 xxb[12]; /* other stuff */
>  guint8 realtick[4]; /* in version 2, units of the timestamps  */
>  guint8 xxc[48]; /* other unknown stuff */
> };
> Forgive me if this has already been covered by a previous post.