osmocom
/
wireshark
11
0
Fork 1
Code Issues Pull Requests Projects Releases Wiki Activity

Update the big time unit comment to reflect Bill Meier's recent changes. 

Fix some other comments.

Add a suggestion for why the realtick values might correlate with
packets having an FCS.

svn path=/trunk/; revision=21993
This commit is contained in:
Guy Harris 2007-05-29 22:52:42 +00:00
parent 4b2284cc35
commit f93cf6dd86
1 changed files with 32 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
wiretap/netxray.c
View File

@ -153,22 +153,7 @@ struct netxray_hdr {
* corresponding network type and captype.
*
* TpS...[] entries of 0.0 mean that no capture file for the
* corresponding captype/timeunit values has yet been seen
*
* Note that the "realtick" value is wrong in many captures, so
* we no longer use it. We don't know what significance it has.
* In at least one capture where "realtick" doesn't correspond
* to the value from the appropriate TpS table, the per-packet header's
* "xxx" field is all zero, so it's not as if a 2.x header includes
* a "compatibility" time stamp corresponding to the value from the
* TpS table and a "real" time stamp corresponding to "realtick".
*
* XXX - the third item is 1193180.0, presumably because somebody found
* it gave the right answer for some captures, but 3 times that, i.e.
* 3579540.0, appears to give the right answer for some other captures.
* Some captures have realtick of 1193182, some have 3579545, and some
* have 1193000. Most of those, in one set of captures somebody has,
* are wrong.
* corresponding captype/timeunit values has yet been seen.
*
* XXX - 05/29/07: For Ethernet captype = 0 (NDIS) and timeunit = 2:
* Perusal of a number of Sniffer captures
@ -180,17 +165,40 @@ struct netxray_hdr {
* (It might be that realtick should be used for Ethernet captype = 0
* and timeunit = 1 but I've not yet enough captures to be sure).
*
* Note that the "realtick" value is wrong in some captures, so
* we don't use it for all captures.
*
* In at least one capture where "realtick" doesn't correspond
* to the value from the appropriate TpS table, the per-packet header's
* "xxx" field is all zero, so it's not as if a 2.x header includes
* a "compatibility" time stamp corresponding to the value from the
* TpS table and a "real" time stamp corresponding to "realtick".
*
* XXX - the item corresponding to timeunit = 2 is 1193180.0, presumably
* because somebody found it gave the right answer for some captures, but
* 3 times that, i.e. 3579540.0, appears to give the right answer for some
* other captures.
*
* Some captures have realtick of 1193182, some have 3579545, and some
* have 1193000. Most of those, in one set of captures somebody has,
* are wrong. (Did that mean "wrong for some capture files, but not
* for the files in which they occurred", or "wrong for the files in
* which they occurred? If it's "wrong for some capture files, but
* not for the files in which they occurred", perhaps those were Ethernet
* captures with a captype of 0 and timeunit = 2, so that we now use
* realtick, and perhaps that fixes the problems.)
*
* XXX - in at least one ATM capture, hdr.realtick is 1193180.0
* and hdr.timeunit is 0. Does that capture have a captype of
* CAPTYPE_ATM? If so, what should the table for ATM captures with
* that captype be?
* and hdr.timeunit is 0. Does that capture have a captype of
* CAPTYPE_ATM? If so, what should the table for ATM captures with
* that captype be?
*/
static double TpS[] = { 1e6, 1193000.0, 1193182.0 };
#define NUM_NETXRAY_TIMEUNITS (sizeof TpS / sizeof TpS[0])
/*
* Table of time units for Ethernet captures with captype ETH_CAPTYPE_GIGPOD.
* 0.0 means "unknown.
* 0.0 means "unknown".
*
* It appears that, at least for Ethernet captures, if captype is
* ETH_CAPTYPE_GIGPOD, that indicates that it's a gigabit Ethernet
@ -835,6 +843,10 @@ int netxray_open(wtap *wth, int *err, gchar **err_info)
* bytes to 'FCS presence' may actually be
* a 'false positive'.
* ToDo: Review analysis and update code.
* It might be that the ticks-per-second value
* is hardware-dependent, and that hardware with
* a particular realtick value puts an FCS there
* and other hardware doesn't.
*/
if (version_major == 2) {
if (hdr.realtick[1] == 0x34 && hdr.realtick[2] == 0x12)