[Guy Harris <gharris@xxxxxxxxx>]

Bill Meier wrote:

> file_name        ver  netw  netw+1 captyp timeunit req'd_tick realtick   hdr.timhi hdr.timlo  pkt1.timehi  pkt1.timelo
> --------------  ----  ----  ------ ------ -------  ---------- --------   --------- ---------  -----------  ------------
> 3Way-Handshake  v2.2    0     0      0       0     1000000    1193182           0      0          3         2833488013
> pingtest.host2  v2.2    0     0      0       0     1000000    3579545           0      0          0           99862327
> v2x1_0_0_0_arp1 v2.1    0     0      0       0     1000000    1193000           0      0          0           10513190
>
> f1              v2.2    0     0      0       0     1000000    1193182           0      0          0            1388474  
>
> f2              v2.2    0     0      0       2     1193182    1193182          838  3086185485    1028      1500901704  hdr.timxx OK
>
> f3              v2.2    0     0      2       0  1000000000    1193182           0      0         121300       57728512  ? gig pod
> f4              v2.2    0     0      2       2    31250000    1193182        2662  1650257505     0              14689  ? gig pod
>
> f5              v2.2    0     0      3       0     1000000    1193182           0      0          0          138804363  ? non-gig pod
> f6              v2.2    0     0      3       2     1250000    1193182         167  3360335544     24        3612438917  ? non-gig pod

So, at least for those captures, it appears that the correct answer 
would be given if there were *more than one* TpS table:

	network = Ethernet, captype = CAPTYPE_NDIS:
		{ 1e6, 1193000.0, 1193182.0 };
	network = Ethernet, captype = ETH_CAPTYPE_GIGPOD:
		{ 1e9, ???, 31250000.0 };
	network = Ethernet, captype = ETH_CAPTYPE_OTHERPOD:
		{ 1e6, ???, 1250000.0 };

It is left as an exercise for readers with non-Ethernet captures, and 
Ethernet captures with a capture type of ETH_CAPTYPE_GIGPOD2 (or any 
other capture types seen for Ethernet captures), to determine what the 
other TpS tables should be.

However, at least at one point, before James Fields and Kevin Johnson's 
change to look at realtick (those changes, according to them, *fixed* 
the interpretation of at least some captures, so the code before their 
change was *clearly* wrong in some cases), the code would, for 2.x 
captures with x != 1 (I don't know whether that was 2.0, 2.2, or both), 
use what amounted to a table of

	{ 1e9, 1193000000.0, 1250000.0 }

(although the middle value might not have been seen) for network = 
Ethernet, captype = ETH_CAPTYPE_GIGPOD - not OTHERPOD (3), but GIGPOD (2).

One of James and Kevin's earlier messages:

	http://www.ethereal.com/lists/ethereal-dev/200412/msg00462.html

mentioned problems with captures with a trace with a value of 6 in a 
particular byte:

> NARRATIVE:  We regularly use distributed Sniffers to capture traffic
> as we're lucky enough to work for a company with a good budget for
> them. But we also use Ethereal to read the traces quite often for a
> variety of reasons most of you will understand.  So it was with some
> disappointment that we found Ethereal to be "broken" in its display
> of packet times when reading traces taken with the new S6040 model
> Sniffers with gigabit blades. Captures would appear to be 1000 times
> slower than they actually were.  Packets 0.005 seconds apart would be
> 5 whole seconds apart in the Ethereal display.
>
> Reading through some of the previous E-mails on the developer and users
> mailing lists as well as the source-code comments, we began looking at
> our capture files in a hex editor. The initial problem seemed simple -
> netxray.c was looking at a particular byte to figure out what kind of
> sniffer trace this was. A value of "02" in that byte would have given us
> a timeunit of a billion (1e9), but our sniffer was inserting a "06" in
> that byte (this seemed to be interpreted as an ISDN HDLC capture). This
> gave us a time unit of a million (1e6). Editing the file to replace the
> 06 with 02 caused Ethereal to "fix" the time problem, but this did not
> solve the problem. We would need to find a new way to evaluate the file
> type, or sniffer type, or *something* to understand that the more
> granular time unit had been used.

*If* the byte in question was the capture type byte, "02" would mean 
ETH_CAPTYPE_GIGPOD and "06" would mean ETH_CAPTYPE_GIGPOD2 (for a WAN 
capture, it's WAN_CAPTYPE_HDLC).

If that's the case, then an additional TpS table would be:

	{ 1e9, ???, ??? }

for network = Ethernet, captype = ETH_CAPTYPE_GIGPOD2.

I'll leave it up to James and Kevin to see whether they can, by proper 
choice of TpS tables, make all the captures they have available to test 
with work as well as they work with their change to use the "realtick" 
value.  Until it can, getting rid of realtick doesn't solve the problem, 
it just shuffles it around, fixing some captures and breaking others....