How Do I Calculate the Timestamp in UTC in an Enhanced Packet Block?

asked 2020-03-13 18:19:36 +0000

trist
5 ●4 ●4 ●6

updated 2020-03-13 19:59:50 +0000

Hello,

Reading the 52 page specification on Pcapng, I've stumbled upon the following when trying to figure out timestamps.

Timestamp (High) and Timestamp (Low): upper 32 bits and lower 32 bits of a 64-bit timestamp. The timestamp is a single 64-bit unsigned integer that represents the number of units of time that have elapsed since 1970-01-01 00:00:00 UTC. The length of a unit of time is specified by the ’if_tsresol’ option (see Figure 10) of the Interface Description Block referenced by this packet. Note that, unlike timestamps in the libpcap file format, timestamps in Enhanced Packet Blocks are not saved as two 32-bit values that represent the seconds and microseconds that have elapsed since 1970-01-01 00:00:00 UTC. Timestamps in Enhanced Packet Blocks are saved as two 32-bit words that represent the upper and lower 32 bits of a single 64-bit quantity. (Page 23 - 24)

http://xml2rfc.tools.ietf.org/cgi-bin...

The specification mentions a couple of things:

I know that I'm dealing with Microseconds, after inspecting the Interface Description Block.
The specification states that these "Timestamps in Enhanced Packet Blocks are saved as two 32-bit words that represent the upper and lower 32 bits of a single 64-bit quantity"... What does this mean?

In essence, I just want to take an upper quantity of: 368776 and a lower quantity of 4040501221 and turn it into: Mar 10, 2020 19:01:40.000050917 Central Daylight Time? The hex dump of this timestamp is: 88 a0 05 00 e5 27 d5 f0. How do I do this?

Thank you for your help.

edit retag flag offensive close merge delete

add a comment

answered 2020-03-13 19:36:55 +0000

cmaynard

11115 ●11 ●317 ●165 https://www.igt.com/

updated 2020-03-13 20:25:05 +0000

The answer lies right in the text you pasted:

The length of a unit of time is specified by the ’if_tsresol’ option (see Figure 10) of the Interface Description Block referenced by this packet.

Referencing Figure 10, you can see that the Options are listed below it in a table, with if_tsresol being option code 9 of fixed length 1. The description of the if_tsresol option then follows:

if_tsresol:

    The if_tsresol option identifies the resolution of timestamps. If the Most Significant Bit is equal to zero, the remaining bits indicates the resolution of the timestamp as a negative power of 10 (e.g. 6 means microsecond resolution, timestamps are the number of microseconds since 1970-01-01 00:00:00 UTC). If the Most Significant Bit is equal to one, the remaining bits indicates the resolution as as negative power of 2 (e.g. 10 means 1/1024 of second). If this option is not present, a resolution of 10^-6 is assumed (i.e. timestamps have the same resolution of the standard 'libpcap' timestamps).
    Example: '6'.

So, if the option is missing, the resolution is assumed to be 10^-6 (microsecond) resolution; otherwise, the value of this option determines the resolution of the timestamps. Here's an example of a pcapng file with an Interface Description Block containing a Timestamp Resolution Option:

Frame 1: 119740 bytes on wire (957920 bits), 119740 bytes captured (957920 bits)
MIME file
PCAPNG File Format
    Block: Section Header Block 1
    Block: Interface Description Block 0
        Block Type: Interface Description Block (0x00000001)
        Block Length: 44
        Block Data
            Link Type: ETHERNET (1)
            Reserved: 0x0000
            Snap Length: 65535
            Options
                Option: Speed = 18446744073709551615
                Option: Timestamp Resolution = 10^-6 (microseconds)
                    Code: Timestamp Resolution (9)
                    Length: 1
                    Timestamp Resolution: 0x06, Base: Power of 10
                       0... .... = Base: Power of 10 (0x0)
                       .000 0110 = Value: 6
                    Option Padding
                Option: End of Options
        Block Length: 44
    Block: Enhanced Packet Block 1
    Block: Enhanced Packet Block 2
    ...

If you then look at a timestamp of one of the Enhanced Packet Blocks, you ought to be able to calculate the timestamp value, knowing that the timestamp resolution is 10^-6. For example, given the following block data:

Frame 1: 119740 bytes on wire (957920 bits), 119740 bytes captured (957920 bits)
MIME file
PCAPNG File Format
    Block: Section Header Block 1
    Block: Interface Description Block 0
    Block: Enhanced Packet Block 1
        Block Type: Enhanced Packet Block (0x00000006)
        Block Length: 284
        Block Data
            Interface: 0x0000
            Timestamp (High): 321818
            Timestamp (Low): 184058695
            [Timestamp: Oct 19, 2013 11:52:49.000322823 Eastern Daylight Time]
            Captured Length: 250
            Packet Length: 250
            Packet Data
            Packet Padding
        Block Length: 284
    Block: Enhanced Packet Block 2
    Block: Enhanced Packet Block 3
    ...

So how was the timestamp computed from the high and low timestamp values of 0x1ae90400 (321818) and 0x4783f80a (184058695), respectively? First, you need to know that these values are in little-endian format, which you find out from information in the Section Header Block. Second, you have to realize this is just a single 64-bit ... (more)

edit flag offensive delete link

Comments

Yes, I noticed that the answer for units of time was in the text I pasted, hence I changed some of the body of my question but forgot to reflect the change in the title. I noticed you have 0x1ae90400 (high) and 0x4783F80A (low). Where did the extra FA in 0x4783f80AFA come from? I'm assuming you mistyped?

Relating this back to my example, if my Hex is 88 a0 05 00 e5 27 d5 f0. To convert this I'd do. High: 0x0005A088 Low: 0xF0D527E5 Time since epoch in microseconds (as an unsigned int64) = (High << 32) | Low ?

I also copied and pasted: 1,382,197,969,322,823 into EpochConverter and got a different number:

Converting 138219796932282:
Assuming that this timestamp is in microseconds (1/1,000,000 second):
GMT: Sunday, May 19, 1974 6:23:16.932 PM
Your time zone: Sunday, May 19, 1974 1:23 ...

(more)

trist ( 2020-03-13 19:59:17 +0000 )edit

Bug 16440 has been submitted to address the file-pcapng.c miscalculation of the timestamp.

cmaynard ( 2020-03-13 20:19:56 +0000 )edit

Yes, the value was a typo. I corrected it. Both high and low values should now be shown as seen in the file, namely in little-endian format.

cmaynard ( 2020-03-13 20:23:43 +0000 )edit

Your timestamps must be in little-endian byte order, so you have to reverse each part to make sense of the timestamp. In other words, 88 a0 05 00e5 27 d5 f0 needs to be converted to a single number whose hex representation is: 0x0005a088f0d527e5. Plugging that value into the timestamp converter, you get:

Assuming that this timestamp is in microseconds (1/1,000,000 second):
GMT: Wednesday, March 11, 2020 12:01:40.050 AM
Your time zone: Tuesday, March 10, 2020 8:01:40.050 PM GMT-04:00 DST
Relative: 3 days ago

NOTE: This value is correct and Wireshark's sub-second value is off by a factor of 1000 due to the bug I've noted.

cmaynard ( 2020-03-13 20:32:01 +0000 )edit

add a comment

How Do I Calculate the Timestamp in UTC in an Enhanced Packet Block?

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

How Do I Calculate the Timestamp in UTC in an Enhanced Packet Block? edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

How Do I Calculate the Timestamp in UTC in an Enhanced Packet Block?