 | 1 | initial version |
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 0x4783f80afa (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 timestamp value representing the number of 10^-6 units of time; therefore we get a single value of 0x0004e91a0af88347 which is 1,382,197,969,322,823 for the timestamp, as measured in the number of microseconds since the Epoch.
Plugging that value (hex or decimal) into a tool such as that provided by https://www.epochconverter.com/, you get:
Assuming that this timestamp is in microseconds (1/1,000,000 second): GMT: Saturday, October 19, 2013 3:52:49.322 PM Your time zone: Saturday, October 19, 2013 11:52:49.322 AM GMT-04:00 DST Relative: 6 years ago
In theory, we've just confirmed and verified the timestamp that Wireshark computed; however, you'll notice that the results are nearly identical, but not quite. If you compare the subseconds value, you'll see that Wireshark indicates .000322823, whereas the Epoch converter indicates .322. These 2 values differ by a factor of 1000, so one of them is clearly wrong. It's trivial to determine which it is though, because dividing 1,382,197,969,322,823 by 1,000,000 converts microseconds to seconds and you get 1,382,197,969.322823. This indicates to me that Wireshark has a bug with respect to reading pcapng timestamps, so filing a Wireshark Bug Report to address this bug is probably a good idea.
| | 2 | No.2 Revision |
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 0x4783f80afa0x0af88347
Plugging that value (hex or decimal) into a tool such as that provided by https://www.epochconverter.com/, you get:
Assuming that this timestamp is in microseconds (1/1,000,000 second): GMT: Saturday, October 19, 2013 3:52:49.322 PM Your time zone: Saturday, October 19, 2013 11:52:49.322 AM GMT-04:00 DST Relative: 6 years ago
In theory, we've just confirmed and verified the timestamp that Wireshark computed; however, you'll notice that the results are nearly identical, but not quite. If you compare the subseconds value, you'll see that Wireshark indicates .000322823, whereas the Epoch converter indicates .322. These 2 values differ by a factor of 1000, so one of them is clearly wrong. It's trivial to determine which it is though, because dividing 1,382,197,969,322,823 by 1,000,000 converts microseconds to seconds and you get 1,382,197,969.322823. This indicates to me that Wireshark has a bug with respect to reading pcapng timestamps, so filing a Wireshark Bug Report to address this bug is probably a good idea.
| | 3 | No.3 Revision |
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 0x0af883470x4783f80a
Plugging that value (hex or decimal) into a tool such as that provided by https://www.epochconverter.com/, you get:
Assuming that this timestamp is in microseconds (1/1,000,000 second): GMT: Saturday, October 19, 2013 3:52:49.322 PM Your time zone: Saturday, October 19, 2013 11:52:49.322 AM GMT-04:00 DST Relative: 6 years ago
In theory, we've just confirmed and verified the timestamp that Wireshark computed; however, you'll notice that the results are nearly identical, but not quite. If you compare the subseconds value, you'll see that Wireshark indicates .000322823, whereas the Epoch converter indicates .322. These 2 values differ by a factor of 1000, so one of them is clearly wrong. It's trivial to determine which it is though, because dividing 1,382,197,969,322,823 by 1,000,000 converts microseconds to seconds and you get 1,382,197,969.322823. This indicates to me that Wireshark has a bug with respect to reading pcapng timestamps, so filing a Wireshark Bug Report to address this bug is probably a good idea.
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.