[Ian Schorr <spamcontrol2@xxxxxxxxx>]

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
>
>

--- Begin Message ---

From: Ian Schorr <spamcontrol2@xxxxxxxxx>

Date: Fri, 28 Feb 2003 18:42:12 -0500

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

--- End Message ---