How to capture live packet count from tshark's stderr?

Question

Tshark prints the packet count about two times per second to stderr when recording to a file. However, it appears to be missing when attempting to monitor the stderr stream from another program.

A simple tshark call with no redirection of stderr:

C:\Users\myUser>tshark -i Wi-Fi -F pcap -w DeleteMe.pcap
Capturing on 'Wi-Fi'
 ** (tshark:14716) 15:49:15.611145 [Main MESSAGE] -- Capture started.
 ** (tshark:14716) 15:49:15.614750 [Main MESSAGE] -- File: "DeleteMe.pcap"
47
tshark:

I believe tshark only uses carriage returns (\r instead of \r\n) so that the update appears on the same line. '47' was the last update before I ended the program. The final packet count summary that appears after "tshark:" is missing.

However, if I redirect stderr to a file (similar results when stderr is monitored by another program):

C:\Users\a1084081>tshark -i Wi-Fi -F pcap -w DeleteMe.pcap 2> out.txt

C:\Users\a1084081>out.txt

I get the following in out.txt:

Capturing on 'Wi-Fi'
 ** (tshark:26228) 15:51:29.006613 [Main MESSAGE] -- Capture started.
 ** (tshark:26228) 15:51:29.006738 [Main MESSAGE] -- File: "DeleteMe.pcap"
tshark: 
16 packets captured

Here there was no live packet count, but I do receive the final packet count after "tshark:"

The fundamental question is: "Why does the output change when I am monitoring the output?"

Our goal is to have live feedback that we are receiving an expected amount of traffic while recording. This allows us to terminate and restart our procedures immediately on any failure. Any alternative suggestions would be appreciated. I am attempting to call and monitor tshark from a C# .NET project.

Answer 1

I ended up spawning a secondary TShark process with -a duration:1 argument to the to run for 1 second. When I check the status, I parse the final packet count if it has exited, and then restart it with the same argument.

Answer 2

"Why does the output change when I am monitoring the output?"

Because TShark check whether the standard error is a terminal and, if it isn't, doesn't print the running packet count, it just prints a final packet count. If the output is being monitored, it's probably going to a file or a pipe, neither of which are terminals.

Answer 3

Don't. Just do not do that. That binary is not designed for monitoring in the way you're trying to make use of it. Instead, consider counting received packets within the application you're developing: that avoids quite some issues to deal with (like picking up a correct interface) and distinguishing your packets from random data the machine might have received so far.