Ask Your Question
0

Wireshark does not correctly display timestamps in pcapng files written by ASG-TMON for TCP/IP

asked 2018-07-25 18:26:05 +0000

djconnell gravatar image

updated 2018-08-03 18:33:39 +0000

Guy Harris gravatar image

I have been tasked with adding a feature to our TCP/IP monitor product, which runs under z/OS on IBM mainframes, that will allow a user create a PCAPng file from packet trace data provided by the TCP/IP stack being monitored. The product also allows the user to create a PCAPng file from an existing z/OS packet trace file. The feature works quite well, but I have recently discovered that something is amiss with the timestamp in the EPB.

The time stamp is a 64-but unsigned binary number taken from the z/architecture TOD clock (sometimes called the STCK time). In Wireshark, if I choose one of the "Seconds since" time formats, the time displayed looks reasonable. However, if I choose a date and time of day format, the time field is blank. I am using Wireshark Version 2.6.2 (v2.6.2-0-g1b3cedbc).

I'm confident that the timestamp field is being correctly populated with the timestamp from the packet trace header, suggesting that Wireshark is expecting something different from what I am giving it. I need to know what Wireshark expects to see. Can anyone help?

edit retag flag offensive close merge delete

Comments

Can you share us a small ( 1 Packet) trace example maybe a ping or something like that?

Christian_R gravatar imageChristian_R ( 2018-07-25 18:54:36 +0000 )edit

https://pcapng.github.io/pcapng/#rfc.section.4.3 describes the Enhanced Packet Block containing the Timestamps

Timestamp (High) and Timestamp (Low): high and low 32-bits of a 64-bit quantity representing the timestamp. The timestamp is a single 64-bit unsigned integer representing the number of units since 1/1/1970 00:00:00 UTC. he way to interpret this field is specified by the 'if_tsresol' option (see Figure 10) of the Interface Description block referenced by this packet.

So, a sample pcapng file documenting your problematic timestamp would certainly help in figuring this out. Ideally accompanied with the original CTRACE dataset.

mrEEde gravatar imagemrEEde ( 2018-07-26 03:29:33 +0000 )edit

This is an EPB as it appears in the PCAPng file I create. The time has been adjusted to make it relative to 1970.

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9
----+----F----+----F----+----F----+----F----+----F----+----F----+----F----+----F----+----F
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9
 -----------------------------------------------------------------------------------------
.......ì....ï.....zè..........!.....!..á..á...&\ .:.ý,...á....2ð...-.8y.HS&...´è.......ì  
000000050000511210A5000300030050030050040040025E40708600040003F801263FA1CE5100B500000005  
0006000800007D9C13940006000680A28480AA658050080000A6DBAA65A2842C05C0D88D820011E400000008  

This is the packet trace entry from which the above EPB was created.  The time is relative to 1900.

CTE   009E0010 00000004 D4AE1DB7 DB099844
+0010 00640000 27000028 D8C4C9D6 D3C9D5D2
+0020 40404040 40404040 D4AE1DB7 DB03F244
+0030 00000000 00000000 0000FFFE 0A0A0645
+0040 00000000 00000000 0000FFFE 0A020834
+0050 F28C0015 00000000 00000000 005C0000
+0060 00000028 0000000B 00000000 00080003
+0070 01000000 45000028 50E04000 7A068D6B
+0080 0A0A0645 0A020834 F28C0015 2C603DF8
+0090 A81DC8E2 50100101 BE540000 009E
djconnell gravatar imagedjconnell ( 2018-07-26 11:19:08 +0000 )edit

This is the IDB as it currently stands. Originally I had no TSresol option. Since adding it, I have tried base 2 and base 10 but neither solved my problem.

----+----1----+----2----+----3 ----+----F----+----F----+----F ----+----1----+----2----+----3


............................
0000000100000000000000000001
0001000C0100000009016000000C

djconnell gravatar imagedjconnell ( 2018-07-26 11:24:26 +0000 )edit

In the CTE, the time stamp is at offset 28

djconnell gravatar imagedjconnell ( 2018-07-26 12:01:35 +0000 )edit

2 Answers

Sort by » oldest newest most voted
0

answered 2018-07-27 14:30:37 +0000

mrEEde gravatar image

updated 2018-07-27 16:47:47 +0000

The TOD Clock from the CTRACE entry you provided
D4AE1DB7DB099844 is 07/25/2018 11:56:47.783065 UTC which is 1532519807.783065000 epoch.
These timestamps have a microsecond granularity I was crafting a pcapng file by using editcap -t to see what the internal representation looked like in a windows generated - little endian - pcapng . image description

Here is the resulting pcapng in hex with a timestamp(hi/lo) of D17105009910C192 at +144 at a time resolution of 10^-6

0000000: 0a0d 0d0a bc00 0000 4d3c 2b1a 0100 0000  ........M<+.....
0000010: ffff ffff ffff ffff 0200 3d00 2020 2020  ..........=.    
0000020: 2020 2049 6e74 656c 2852 2920 436f 7265     Intel(R) Core
0000030: 2854 4d29 2069 332d 3332 3137 5520 4350  (TM) i3-3217U CP
0000040: 5520 4020 312e 3830 4748 7a20 2877 6974  U @ 1.80GHz (wit
0000050: 6820 5353 4534 2e32 2900 0000 0300 1e00  h SSE4.2).......
0000060: 3634 2d62 6974 2057 696e 646f 7773 2031  64-bit Windows 1
0000070: 302c 2062 7569 6c64 2031 3530 3633 0000  0, build 15063..
0000080: 0400 3000 4475 6d70 6361 7020 2857 6972  ..0.Dumpcap (Wir
0000090: 6573 6861 726b 2920 322e 342e 3020 2876  eshark) 2.4.0 (v
00000a0: 322e 342e 302d 302d 6739 6265 3066 6135  2.4.0-0-g9be0fa5
00000b0: 3030 6429 0000 0000 bc00 0000 0100 0000  00d)............
00000c0: 7c00 0000 0100 0000 ffff 0000 0200 3200  |.............2.
00000d0: 5c44 6576 6963 655c 4e50 465f 7b31 3134  \Device\NPF_{114
00000e0: 3833 3434 382d 3436 4445 2d34 4344 352d  83448-46DE-4CD5-
00000f0: 3837 3343 2d42 3731 3446 4638 3946 3335  873C-B714FF89F35
0000100: 377d 0000 0900 0100 0600 0000 0c00 1e00  7}..............
0000110: 3634 2d62 6974 2057 696e 646f 7773 2031  64-bit Windows 1
0000120: 302c 2062 7569 6c64 2031 3530 3633 0000  0, build 15063..
0000130: 0000 0000 7c00 0000 0600 0000 5800 0000  ....|.......X...
0000140: 0000 0000 d171 0500 9910 c192 3600 0000  .....q......6...
0000150: 3600 0000 6036 dd98 9414 001d aa5c 0f60  6...`6.......\.`
0000160: 0800 4500 0028 1269 0000 fe06 270a c0a8  ..E..(.i....'...
0000170: 0101 c0a8 010b 0050 c65e e1cc a541 b6f7  .......P.^...A..
0000180: 598c 5010 6400 6a36 0000 0000 5800 0000  Y.P.d.j6....X...

I created new files with a tiemstamp 1 microsecond apart. 
d171 0500 9910 c192 
d171 0500 9a10 c192
d171 0500 9b10 c192
d171 0500 9c10 c192
d171 0500 9d10 c192
65536 microseconds apart 
d171 0500 9910 c292

That revealed that the timestamp is in little endian notation,

So to get the correct timestamp into wireshark use epochtime*1000000+epochtime_fractions 0571d192c11099 and convert it to little endian d171 0500 9910 c192

edit flag offensive delete link more

Comments

2

Wireshark can also show a pcapng file in "file" view, so you can see the timestamp fields and their hex values.

Open the file as normal and then from the menu select View -> Reload as File Format/Capture.

grahamb gravatar imagegrahamb ( 2018-07-27 14:39:36 +0000 )edit
1

Note that "epochtime" is "the number of units since 1/1/1970 00:00:00 UTC"; the S/370-and-later TOD clock is not in a count of units since that date and time, so it must be adjusted to be a count of units (either 10^-n or 2^-n) since that date and time.

Guy Harris gravatar imageGuy Harris ( 2018-07-27 17:19:18 +0000 )edit

Fantastic response. Much obliged for your effort. Thanks.

djconnell gravatar imagedjconnell ( 2018-07-27 17:53:49 +0000 )edit

In the response provided by mrEEde, how did you calculate the epoch time? I understand the epoch begins in 1970.

djconnell gravatar imagedjconnell ( 2018-07-31 15:26:39 +0000 )edit
0

answered 2018-08-02 18:29:26 +0000

djconnell gravatar image

The solution was two-fold:
(1) Adjust the TOD clock time to epoch time (2) Shift the result right by 12 bits. The shift puts bit 51 of the TOD clock in the units position of time field. Bit 51 of the TOD clock is incremented by one every microsecond.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2018-07-25 18:26:05 +0000

Seen: 43,442 times

Last updated: Aug 03 '18