Wireshark · Ethereal-dev: Re: [Ethereal-dev] netxray.c patch

[Kevin Johnson <kjohnson@xxxxxxxxxxxxxxx>]

On Sun, 2005-01-02 at 22:46, Guy Harris wrote:
> "Reversing the order of the bytes" is rarely the right thing to do with 
> a capture file format, as most of them are written in a standard byte 
> order, but Ethereal doesn't run on machines with any particular byte 
> order - most machines running it might be little-endian x86 PC's, but 
> I'm running it on a big-endian PowerBook.  "Reversing the order of the 
> bytes", if correct on a little-endian machine, would be wrong on a 
> big-endian machine, and *vice versa*.
> 

Dang, we forgot that part.<g>  Thanks for catching it.


> > We ended up only reading in 12 bytes to xxb[], then grabbing a 32-bit value for a new variable
> > "realtick", and grabbing the remaining 48 bytes into the new array variable "xxj[]".
> 
> By "variable" you presumably mean "structure member".
> 

Yes.

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

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

> It might be that the interpretation of that field is *supposed* to 
> depend on the network type, with a value of 6, for an Ethernet capture, 
> referring to a particular model of gigabit pod, different from the value 
> of 2 for other gigabit pods.
> 

Interesting idea... we will continue to look at it.

> >
> > We then postulated that Sniffer has probably been using the same
> > location for encoding the time ticks value for a long time, and that it
> > might prove fruitful to try using that value ALL the time. We did this,
> > and tested against many captures taken with various versions of the Sniffer
> > code over a 7 year period, and including ethernet, gigabit ethernet,
> > token ring, FDDI, and various WAN types. We do not seem to have broken or
> > worsened Ethereal's ability to display the correct time for any of these,
> > and in most cases have at least slightly improved the accuracy (as compared
> > with the times displayed by the brand-name Sniffer product). In the process
> > we have also fixed the issue with newer gigabit captures being off by a factor of 1000.
> 
> I have a file with a version of 001.100 that has a time stamp in units 
> of microseconds - the new code gets the time stamps very wrong (as in 
> "thinks the packets were captured in 1932"), as the bytes at the 
> "realtick" location in the file header don't appear to correspond to 
> time stamp units.  I also have a file that apparently came from an old 
> version of NetXRay, before it used "XCP" as the magic number, with a 
> similar problem...
> 
> ...and a file with a version of 002.001 with a similar problem.
> 
> In the 002.001 file, the realtick value is 0, which is clearly bogus. 
> The "capture type" value is 0, for NDIS; however, I have one capture 
> with a network type of 0 (Ethernet) and capture type 0 (NDIS), so there 
> *are* NDIS captures with non-zero realtick values (and the value is 
> close to the value derived from the TpS table, so it's probably valid).
> 

Odd, the captures we had that we not 002.xxx worked with our code.  Any
way we could get copies of your captures?

> Do you have any files with non-002.xxx versions on which you've tested? 
>   If not, the time stamp units in the header might have been introduced 
> in the 002.xxx file format (the file format version number doesn't 
> directly correspond to the application version number) - older files 
> appear to have millisecond time stamps, with version 001.100 introducing 
> microsecond time stamps, so it might be the case that version 002.xxx 
> might be the version where they switched to time stamps with the units 
> recorded in the file header.
> 
> I don't know whether there's any field that indicates whether to get the 
> time stamp from the realtick value or the timeunits value, other than 
> the realtick value itself (if 0, use timeunits).
> 
> Note that the "capture type" field also only appears to be in the 
> 002.xxx file format.
> 
> > 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've checked in the patch, with the modifications indicated above. 
> Thanks for being the ones to finally figure out where the hell the 
> Sniffer folks hid the time stamp!

We will continue to look into more changes for this file.  

Thanks for the pointers.
Kevin and James
-------------------
BASE Project Lead
http://sourceforge.net/projects/secureideas
http://base.secureideas.net
The next step in IDS analysis!

Attachment: signature.asc
Description: This is a digitally signed message part