Revision history [back]

In the file you shared the recorded time jumps 82 secs backwards between frame 8 and 9 as shown below. If you filter this out and save this into a new file (e.g. using tshark -r {FILE} -Y "ip.src=={IP} or ip.dst=={IP}" -w newfile.pcapng) the statistics function works fine.

So apparently Tshark's io-stat and Wireshark's graph cannot handle (big) negative time deltas.
I am not sure if this counts as a bug, because delta time should not be negative.

Check how the time is recorded during capturing.
The reported timestamp precision of the file is: nanoseconds. I assume that is incorrect (most used is microseconds) and causing the misinterpretation.

tshark -r 15-06-22_tshark_anon.pcapng -T fields -e frame.number -e frame.time_delta -Y 'frame.number in {7..11}'
7       0.002824243
8       0.000141622
9       -82.374695950
10      0.405914565
11      0.276358835

In the file you shared the recorded time jumps 82 secs backwards between frame 8 and 9 as shown below. If you filter this out and save this into a new file (e.g. using tshark -r {FILE} -Y "ip.src=={IP} or ip.dst=={IP}" -w newfile.pcapng) the statistics function works fine.

So apparently Tshark's io-stat and Wireshark's graph cannot handle (big) negative time deltas.
I am not sure if this counts as a bug, because delta time should not be negative.

Check how the time is recorded during capturing.
The reported timestamp precision of the file is: nanoseconds. I assume that is incorrect (most used is microseconds) and causing the misinterpretation.

tshark -r 15-06-22_tshark_anon.pcapng -T fields -e frame.number -e frame.time_delta -Y 'frame.number in {7..11}'
7       0.002824243
8       0.000141622
9       -82.374695950
10      0.405914565
11      0.276358835