Wireshark · Ethereal-dev: Re: [Ethereal-dev] Display time issue

[Ian Schorr <spamcontrol2@xxxxxxxxx>]

Sorry about the repost - in addition, I'm looking for files that are 
002.000 or above, have hdr.timeunit set to 1 or 2, and seem to exhibit 
the odd timestamp shifting that is checked for in netxray.c/netxray_open.

Ian

Ian Schorr wrote:

> 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
> > >
> > >  
>
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev