Re: [Ethereal-dev] netxray.c patch

[Guy Harris <gharris@xxxxxxxxx>]

Kevin Johnson wrote:
> On Sun, 2005-01-02 at 22:46, Guy Harris wrote:

> > > The only Sniffer captures where timestamp display is not improved are
> > > ATM captures made with the older ATM pods - and these are no worse than
> > > in the existing version of Ethereal - they simply have not changed.
> >
> > So the "realtick" value in those captures is the same as the value that 
> > the old code chose?  What's the file format version number in those 
> > files, and what's the "capture type" (xxj[4]/xxc[4]) value for those 
> > files?  Are the time stamps wrong because the units are wrong (in which 
> > case the amount by which the time stamps are off would change from 
> > packet to packet), or because the start time is wrong (in which case all 
> > the time stamps would be off by the same amount)?
> >
> > Do you have any captures of that sort that you could send us?
>
> Not sure if we can send the captures as they were part of Sniffer
> Training and so may not be redistributable.  We will check.

If they're not redistributable, it'd still be interesting to see the 
answer to the other questions - did your changes not help because the 
files didn't have a "realtick" value (i.e., it was 0, which appears to 
mean "present"), so that the Ethereal code has to use the hdr.timeunit 
field (in which case perhaps the TpS array is wrong - the values in 
there have been tweaked to fix problems, but if those problems were with 
files where the correct timestamp units were in a non-zero realtick 
value, the changes to TpS might have been wrong), or did they not help 
because the "realtick" values were wrong?

> > Did it cause Ethereal to misinterpret the capture?
>
> It made Ethereal use the wrong tick value to determine time stamps. 
> Which made any time values unusable.

Sorry, I might not have stated that clearly - "it" referred to patching 
the capture type value to be 2 rather than 6; that change fixed the time 
stamps, but did it then cause Ethereal to misinterpret the packet 
contents (e.g., interpreting ISDN traffic as Ethernet traffic)?

> > > As an interesting side note, there is a check being performed to determine whether or not
> > > to honor the FCS bits at the end of each packet.  The check is based on the hex values of
> > > two bytes - right in the middle of the time stamp.  It turns out these two bytes are only
> > > valid if the "real" time unit is near the 1193180 value, so it is likely Ethereal has been
> > > ignoring the FCS information when some folks think it has been used.
> >
> > Do you mean "ignoring the FCS information when it's present" or 
> > "treating the data at the end of the packet like an FCS when it's not an 
> > VCS"?
>
> Ignoring it when it is present.

I.e., Ethereal's been treating the 4 bytes at the end of the packet as 
junk when it should have been treated as an FCS?  If the real check 
should be for a "realtick" value near (for some value of "near") 
1193180, that check would, I think, make it *less* likely that Ethereal 
would treat the 4 bytes at the end of the packet as an FCS, rather than 
*more* likely, as it'd involve checking the high-order bits of the 
"realtick" value against the proper value, rather than ignoring those 
bits as Ethereal has been doing.

I wonder whether the presence of FCS data is, in some sense, 
unintentional, i.e. they didn't decide to put it there, some hardware 
(whether it's a pod or a regular Ethernet interface) just happens to put 
it there sometimes, and when capturing with that hardware, the time 
stamp value happens, for whatever reason, to be in the range 1193180.

Does Sniffer ever display those bytes as an FCS?