[Ian Schorr <spamcontrol2@xxxxxxxxx>]

Does anyone have a small 002.001 or 002.000 trace that they can email to 
me, or know under what circumstances/versions Sniffer/NetXRay will 
produce such a file?

Thanks,
Ian

Ian Schorr wrote:

> I've also noticed that in all the traces that I have so far, setting 
> the netray_hdr byte to something non-zero (or at least 1-5, which I've 
> tested) seems to cause Sniffer to multiply frame timestamp fields by 
> 32 when interpreting them.  This has been true in all traces I've 
> tried, and the traces I have where this byte is set (to 2, in all the 
> traces I've found it set in), the timestamp fields seem to be 32 times 
> too small.
>
> This certainly seems to differ from how Ethereal is converting the 
> timestamps when this field is set to 1 or 2.
>
> All of my traces seem to be 002.002, so I'm not sure if this is simply 
> a difference between 002.001 (and 002.000, I assume) and 002.002.  I'm 
> also not sure that this field isn't tied to another, undeciphered 
> field.  In any case, having Ethereal account for this field (right now 
> I multiply by 32 only if the version is 002.002, otherwise I use the 
> old conversion) and the xxb[20] field have fixed the timestamps for 
> all the traces I've looked at so far.
>
> I'll let you know if I find anything else in testing.  Let me know if 
> there's anything I can provide, like traces that have this value set 
> originally (not "modified" by me manually).
>
> Ian Schorr
>
> Guy Harris wrote:
>
> > On Thu, Feb 27, 2003 at 04:10:03PM -0500, Ian Schorr wrote:
> >  
> >
> > > From what I can tell, setting a value for xxb[20] (from the 
> > > netxray_hdr structure in netxray.c) seems to instruct Sniffer to 
> > > interpret the timestamps differently.  Ethereal doesn't currently 
> > > check the value of this field.
> > >
> > > Setting it to a value of 0x2, which I see in nearly all traces I 
> > > have that were taken with a gigabit ethernet sniffer, seems to cause 
> > > Sniffer to divide the timestamps by 1000.
> > >   
> >
> >
> >
> > I.e., the time stamps have higher resolution (e.g., if hdr.timeunit is
> > 0, they have nanosecond resolution rather than microsecond resolution)?
> >
> >  
> >
> > > I've also noticed that setting this value to something other than 2 
> > > seems to cause Sniffer to not display A and B channel information on 
> > > gigabit-taken traces, so I'm guessing that this field may somehow 
> > > indicate the capture type (i.e. this trace was taken with a 
> > > "high-speed module", or something like that).
> > >   
> >
> >
> >
> > At least in the current CVS version (I think it's in 0.9.9 as well), for
> > WAN captures, hdr.xxb[20] appears to indicate the type of capture:
> >
> >     4    Frame Relay
> >     6    various sorts of HDLC
> >
> > so I suspect it does, in fact, indicate something about the type of
> > captue (I don't know whether Frame Relay captures use a different type
> > of pod from other captures - I don't think they do - so it's probably
> > hardware plus other information).
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
> >  
>
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [Ethereal-dev] Display time issue
> From:
> Ian Schorr <spamcontrol2@xxxxxxxxx>
> Date:
> Fri, 28 Feb 2003 18:42:12 -0500
> To:
> Guy Harris <guy@xxxxxxxxxx>
>
>
> Guy,
>
> You're right, 0.9.9 does have that code - in fact, I was staring at 
> that section right before I sent the message, so I'm not sure why I 
> didn't notice the xxb[20] field checks...
>
> I've also noticed that in all the traces that I have so far, setting 
> the netray_hdr byte to something non-zero (or at least 1-5, which I've 
> tested) seems to cause Sniffer to multiply frame timestamp fields by 
> 32 when interpreting them.  This has been true in all traces I've 
> tried, and the traces I have where this byte is set (to 2, in all the 
> traces I've found it set in), the timestamp fields seem to be 32 times 
> too small.
>
> This certainly seems to differ from how Ethereal is converting the 
> timestamps when this field is set to 1 or 2.
>
> All of my traces seem to be 002.002, so I'm not sure if this is simply 
> a difference between 002.001 (and 002.000, I assume) and 002.002.  I'm 
> also not sure that this field isn't tied to another, undeciphered 
> field.  In any case, having Ethereal account for this field (right now 
> I multiply by 32 only if the version is 002.002, otherwise I use the 
> old conversion) and the xxb[20] field have fixed the timestamps for 
> all the traces I've looked at so far.
>
> I'll let you know if I find anything else in testing.  Let me know if 
> there's anything I can provide, like traces that have this value set 
> originally (not "modified" by me manually).
>
> Ian Schorr
>
> Guy Harris wrote:
>
> > On Thu, Feb 27, 2003 at 04:10:03PM -0500, Ian Schorr wrote:
> >  
> >
> > > From what I can tell, setting a value for xxb[20] (from the 
> > > netxray_hdr structure in netxray.c) seems to instruct Sniffer to 
> > > interpret the timestamps differently.  Ethereal doesn't currently 
> > > check the value of this field.
> > >
> > > Setting it to a value of 0x2, which I see in nearly all traces I 
> > > have that were taken with a gigabit ethernet sniffer, seems to cause 
> > > Sniffer to divide the timestamps by 1000.
> > >   
> >
> >
> > I.e., the time stamps have higher resolution (e.g., if hdr.timeunit is
> > 0, they have nanosecond resolution rather than microsecond resolution)?
> >
> >  
> >
> > > I've also noticed that setting this value to something other than 2 
> > > seems to cause Sniffer to not display A and B channel information on 
> > > gigabit-taken traces, so I'm guessing that this field may somehow 
> > > indicate the capture type (i.e. this trace was taken with a 
> > > "high-speed module", or something like that).
> > >   
> >
> >
> > At least in the current CVS version (I think it's in 0.9.9 as well), for
> > WAN captures, hdr.xxb[20] appears to indicate the type of capture:
> >
> >     4    Frame Relay
> >     6    various sorts of HDLC
> >
> > so I suspect it does, in fact, indicate something about the type of
> > captue (I don't know whether Frame Relay captures use a different type
> > of pod from other captures - I don't think they do - so it's probably
> > hardware plus other information).
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
> >