["James V. Fields" <jvfields@xxxxxxx>]

What I'd like to do is see if I can generate one of those captures with
timehi:timelo = zero.  We have a number of hardware/software
combinations of the brand-name Sniffer products and we almost never
capture straight to a file.  What I meant by "expert" is that the
Sniffer has built-in diagnoses and statistics which are applied to the
capture - this is referred to as the Expert window or tab, and under a
"normal" capture - i.e. one not written directly to disk - the capture
goes into a memory buffer and is run through "Expert" on the fly.  It is
after you tell the Sniffer to stop and display the capture that
additional windows include the decode appear.  The only exception to
that in our own equipment are gigabit sniffers where the capture is done
in a buffer on the gig card itself, and having it uploaded to the buffer
on the fly is an option rather than the default.

I'll try to take some samples with various settings early next week.

Ken Mann wrote:
>  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 
> <mailto:ethereal-users@xxxxxxxxxxxx>>
> Message-ID: <41F96606.3070300@xxxxxxx <mailto: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.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-users