This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

How to dissect a UTC timestamp

0

I am trying to write a customized dissector as a plugin on windows platform.

I am doing this on version 2.1.1-git, win32.

Details of the data:
It is a UTC Timestamp. The number of nanoseconds since January 1, 1970, 00:00:00 GMT, precision is provided to the nearest millsecond.
The format of this field is Uint64.

I have the following code to dissect a UTC time stamp with 64 bit, in little endian:

void 
proto_register_foo(void) {
    static hf_register_info hf[] = {
        { &hf_foo_send_time, { "FOO SendTime", "foo.sendtime", FT_ABSOBUTE_TIME, ABSOLUTE_TIME_UTC, NULL, 0x0, NULL, HFILL }}
    };
    ... 
}

static int
dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree U, void *data U)
{
…
proto_tree_add_item(omdd_tree, hg_omdd_send_time, tvb, 0, 8, ENC_LITTLE_ENDIAN);
…
}

The problem is the result is not correct. Does anyone know how to dissect a UTC time stamp?

asked 06 Jul ‘16, 19:00

SulfredLee's gravatar image

SulfredLee
26●4●4●8
accept rate: 0%

edited 06 Jul ‘16, 22:28

What do you mean by “a UTC time stamp”? What are the units of the time stamp? Seconds? Fractions of a second? If it’s fractions of a second, what fraction - microseconds, nanoseconds, other? Is the time stamp a count of fractions of a second, or seconds, since some point in time? If so, what is that point in time? Is it, for example, January 1, 1970, 00:00:00 UTC? Or is it, for example, a 32-bit count of seconds since some point in time and a 32-bit count of fractions of a second since the second in question? Without knowing that, nobody can know how to dissect it.

(06 Jul ‘16, 20:49) Guy Harris ♦♦

Sorry for leak of information.
I got the description from the development guide is that:
It is a UTC Timestamp. The number of nanoseconds since January 1, 1970, 00:00:00 GMT, precision is provided to the nearest millsecond.
The format of this field is Uint64.

(06 Jul ‘16, 20:53) SulfredLee

One Answer:

2

Unfortunately, there is currently no ENC_ value for that time stamp format, so you would have to do it manually:

guint64 timestamp;
nstime_t ts_nstime;

...



timestamp = tvb_get_letoh64(tvb, 0, 8);
ts_nstime.secs = timestamp / 1000000000;
ts.nstime_nsecs = timestamp % 1000000000;
proto_tree_add_time(omdd_tree, hg_omdd_send_time, tvb, 0, 8, &ts_nstime);

answered 07 Jul ‘16, 00:35

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k●3●35●196
accept rate: 19%

Thank you very much, it works.

(07 Jul ‘16, 01:17) SulfredLee

Sorry, one more question. I have already get the value to ts_nstime. Why I still have to use the data in tvb at the api proto_tree_add_time ?

(07 Jul ‘16, 01:54) SulfredLee

Because you want the value of the field to be in the protocol tree, and fetching the value from the packet and converting it to a nstime_t doesn’t put it into the protocol tree - only a proto_tree_add_ call can do that.

(07 Jul ‘16, 02:08) Guy Harris ♦♦

Here is my understanding, when I put &ts_nstime into proto_tree_add_time, this api will ignore the present of tvb, 0, 8, am I correct @@?

(07 Jul ‘16, 02:15) SulfredLee
1

No, you are not correct. It will not fetch the data from the tvbuff, but it will record that the data came from the tvbuff, starting at an offset of 0, for 8 bytes, so that, for example, if you click on on the item in the protocol details pane it will highlight the corresponding data in the hex dump pane.

(07 Jul ‘16, 02:47) Guy Harris ♦♦