Tshark output incomplete in real time

edit

Using "tshark -r -" as in:

$ tail -f -c +0 demo.pcap | tshark -r -

Results in two concurrent processes:

$ ps -eaf

...

501 20361 4116 0 10:03AM ttys000 0:00.56 tail -f -c +0 demo.pcap

501 20362 4116 0 10:03AM ttys000 0:00.44 /Applications/Wireshark.app/Contents/MacOS/tshark -r -

...

Using "tshark -i -" as in:

$ tail -f -c +0 demo.pcap | tshark -i -

Results in three concurrent processes:

$ ps -eaf

...

501 20406 4116 0 10:09AM ttys000 0:00.57 tail -f -c +0 demo.pcap

501 20407 4116 0 10:09AM ttys000 0:00.45 /Applications/Wireshark.app/Contents/MacOS/tshark -i -

501 20423 20407 0 10:09AM ttys000 0:00.09 /Applications/Wireshark.app/Contents/MacOS/dumpcap -n -i - -Z none

...

In your examples 2, 3 and 4 you start your pipeline with the command: "tail -f -c +0 demo.cap". As you are aware the tail command with the -f option does not simply exit when it sees EOF; instead it stays open testing to see if any new data is appended to the demo.cap.

In your "... | tshark -Tek -r -" and "... | tshark -Tek -l -r -" cases you are telling tshark to read from a file but the use of the "-" indicates that the file should be the STDIN file handle. In the "... | tshark -Tek -i - " case you are telling tshark to read from a device but the use of the "-" indicates the use of STDIN as a pipe. The tshark -i - case will cause tshark to spawn a dumpcap process to read data from the pipe and pass the data up to tshark similar to the way a live capture data is read.

When using the "tshark -r -" and "tshark -l -r -" options it appears that the last buffer's worth of data may not be reliably accessible to tshark when the pipeline is signaled to terminate.