Ethereal-users: [Ethereal-users] RE: netxray.c Time Calculations (file version 2.2)
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.
