Ask Your Question

Differences between Tshark bitrate output command and Wireshark graph?

asked 2022-01-28 20:01:28 +0000

CNK992 gravatar image

updated 2022-01-31 16:13:34 +0000

grahamb gravatar image

Hello. I am running a setup where I SSH into a server that has access to several devices. This machine is running the 64-bit Tshark version 3.2.14.
Out of those devices, I am running TShark on two PIs that are communicating, capturing to a file, and then transferring that PCAPNG file over to the server. These PIs are using 32-bit Tshark version 3.2.14.

On the server, after transferring, I am calling:

tshark -r {FILE} -2 -R "ip.src=={IP} or ip.dst=={IP}" -t ud -q -z io,stat,1

This spits out information regarding the bitrate which looks like the following:

| 2022-01-20 15:06:41 |    378 | 151872 |  
| 2022-01-20 15:06:42 |    383 | 155352 |  
| 2022-01-20 15:06:43 |    414 | 155804 |  
| 2022-01-20 15:06:44 |    419 | 157656 |  
| 2022-01-20 15:06:45 |    414 | 156554 |  
| 2022-01-20 15:06:46 |    412 | 155644 |  
| 2022-01-20 15:06:47 |    442 | 159942 |

For most runs, this is perfectly fine. I can transfer the files over to my local Windows machine (running a 64-bit 3.2.14 version of TShark/Wireshark) and the IO graph matches the text output.

However, some runs are showing the following output:

| 2022-01-20 15:07:20 |    342 | 132810 |  
| 2022-01-20 15:07:21 |      0 |      0 |


| 2022-01-20 11:58:55 |    248 | 97222 |  
| 2022-01-20 11:58:56 |     23 |  8474 |  
| 2022-01-20 11:58:57 |     22 |  8410 |  
| 2022-01-20 11:58:58 |     22 |  8810 |

where the first line is unreasonably large in "frames" and "bytes" columns. When I pull it over to my machine and open the graph, I am not seeing this. Everything looks normal. For a 9kB test, I get the usual ~8.4kB results. If I go to the main Wireshark window and apply the same src/dst filter, I can see all of the packets, manually add their size for the first 1-second interval, and I can confirm that the packet info matches the graph.

For the particular run that shows the "342 frames, 132810 bytes" in the first-second interval, I am actually not seeing any traffic on the IO graph, but I do see all of the packets in the main Wireshark page. For this scrambled page, it appears to be as the ip.src||ip.dst filter.

Any idea what causes this difference between the textual command and the Wireshark view? Does it relate at all to me not seeing any of the filtered packets on the IO graph? Or perhaps why I still keep seeing the window go out to 250,000 seconds?
When I attempt to upload a file, I am told that I do not have enough points, so please let me know what other info you may need to help track down the issue!
EDIT: Here is the file link,

edit retag flag offensive close merge delete


Put the file(s) you would like to share on a public file share - Dropbox, Google, Microsoft, ... - then update your question with a link to them.

Chuckc gravatar imageChuckc ( 2022-01-28 22:04:21 +0000 )edit

Thank you, I have just edited now with the link

CNK992 gravatar imageCNK992 ( 2022-01-31 15:57:54 +0000 )edit

Can you add the output of tshark -v from one of the capture RPi?

Chuckc gravatar imageChuckc ( 2022-01-31 22:56:49 +0000 )edit

1 Answer

Sort by » oldest newest most voted

answered 2022-01-31 21:41:31 +0000

André gravatar image

updated 2022-01-31 21:54:45 +0000

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.

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
edit flag offensive delete link more


Interesting. I use UTC time, and I see the first 8 packets are in order, but afterward, it starts "before" those frames and continues like normal. I have seen this occur before and never put much thought to it since they always seem to be packets unrelated to what we're looking for. Broadcasts, PTP (if it's running), etc... However, you are indeed correct. Filtered that out and both IO Graph and textual output are correct.

I will mess with timestamp args to see if I can replicate the problem or if it fixes it. For the files I already have, it looks like filtering them into new files will be the easy way to go. I appreciate the help!

CNK992 gravatar imageCNK992 ( 2022-02-01 00:42:43 +0000 )edit

How is the system time set on the capture system and is it possible that it is updated during the capture?

Chuckc gravatar imageChuckc ( 2022-02-01 01:32:18 +0000 )edit

System times on both devices are set to UTC. I do not have NTP synchronization or anything turned on. The (original) filenames are using timestamps and those give no indication that the time is ever being updated. It's normally something I do manually when I connect them to a device I want them to sync to.

CNK992 gravatar imageCNK992 ( 2022-02-04 16:10:02 +0000 )edit

The timezone setting (UTC) is only used when converting the unix time stamp to 'human readable' format. It does not affect how it is stored.

You wrote that tshark is used to capture to file. In that case tshark merely functions as a wrapper around dumpcap. So it is better to run dumpcap directly.

In pcapng the timestamp is stored as a 64-bit number while in pcap it is stored as two 32-bit numbers (secs and sub-secs). Maybe there is a bug in the 32-bit version or libpcap? I wonder if the problem disappears when you switch to pcap format.

André gravatar imageAndré ( 2022-02-05 20:02:33 +0000 )edit

Your Answer

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

Add Answer

Question Tools



Asked: 2022-01-28 20:01:28 +0000

Seen: 1,396 times

Last updated: Jan 31 '22