 | 1 | initial version |
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
| | 2 | No.2 Revision |
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