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

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Ian Schorr <spamcontrol2@xxxxxxxxx>
Date: Thu, 06 Mar 2003 18:23:49 -0500
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