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