Re: [ethereal-dev] no 64 bit support, gryphon plugin

[Guy Harris <gharris@xxxxxxxxxxxx>]

On Thu, Aug 10, 2000 at 08:23:24AM +0200, Uwe Girlich wrote:
> It looks like in the protocol we have a 64 bit number which holds the number
> seconds * 100000, which is good for 5 fraction digits. But to interpret
> the lnglng overlaying 2 uint is an assumtion about the order of the 2 uint
> in the guint64. It will work on little-endian systems only.
> 
> The first timestamp (ts.lnglng / 100000L) should be obviously the number of
> seconds (ctime() needs it so) but what is the second timestamp (ts.lng[0]).
> From the following lines (hours = ...) it should probably be the originally
> value ts.lnglng, because every following statement has its own division
> by 100000.

I'm suspicious of this; the Gryphon protocol is documented at

	http://www.dgtech.com/gryphon/docs/html/GCprotocol/

and says, of the CMD_GET_TIME command the code in question dissects:

	Response data length is four bytes. 

	TIME -- 8 bytes -- Timestamp, in units of .00001 sec.  (Lower
	four bytes correspond to Gryphon Data Frame timestamp, upper
	four bytes add more significant bits.)

I suspect "Response data length is four bytes." is the result of cutting
and pasting without editing.

By "more significant bits" I'd assume they provided higher resolution;
given that elsewhere in the protocol time resolution is also .00001 sec,
though, I suspect it really means "larger range".

The sample output in the documentation for the "gryphrx" utility":

	http://www.dgtech.com/gryphon/docs/html/utils/gryphrx.html

shows times with more than 32 bits of data, although they seem to show
that as part of the header time stamp, which is only 32 bits wide.

So I don't know what the heck is going on here - I'm CCing Steve
Limkemann of Dearborn Technology Group, to see if he can explain this.

> > (BTW, this indicates that we should provide "pntohll()" and "phtonll()"
> > routines, and tvbuff versions of them, at least on platforms where we
> > have "gint64" and "guint64".)
> That would at least clean the first mentioned problem.

I've checked that in.