Tshark stopping unexpectedly due to read from file failure
Summary
I'm experiencing an issue where tshark is stopping unexpectedly. I have a process streaming pcapng data over a TCP socket to tshark and using tshark's TCP@ interface type on the command line. Most of the time everything will be fine but every now and then tshark will stop right away and print "0 packets captured" to stderr. This seems to occur much more frequently when running tshark as a subprocess in a python script, however it also occurs when launching tshark from the command line.
Steps to reproduce
I can reproduce this just by running "tshark -i TCP@127.0.0.1:19000". I have a zigbee network running in the background sending packets, which are getting streamed over the TCP socket as pcapng. If packets appear, I will restart tshark and try again until the bug occurs.
You might be able to reproduce the test using the successful capture linked below and "cat tshark_out.pcapng | nc -l 19000" and then "tshark -i TCP@127.0.0.1:19000" on the other end
What is the current bug behavior?
Before any packets are written to stdout, tshark.c calls sync_pipe_stop which ends the capture session. Right before that, inside wtap_read *err gets set to -12 which is WTAP_ERR_SHORT_READ. Looking a little deeper, it looks like pcapng_read_block() is called from wiretap/pcapng.c and returns PCAPNG_BLOCK_NOT_SHB, due to a short read or EOF.
There could be some timing problem with writes in dumpcap to the /tmp/wireshark_*****.pcapng file being flushed and the read from tshark of that record.
Sample capture file
In the following capture I used the same interface and specified the outfile using -w. I also used -P to print a preview of the packets to stdout, however the packets in the file were never printed. stderr claims 0 packets were captured. Ignore the time field of the packets, that information is obviously incorrect. tshark_out5.pcapng
Here is a successful capture for comparison tshark_out.pcapng
Relevant logs and/or screenshots
This is an strace log taken during one of the failures tshark_strace_fail
This includes a couple debug logs my colleague sent me. The first half is from dumpcap, the second half is from tshark dumpcap_debug_log.tmp
Build information
TShark (Wireshark) 3.1.0 (v3.1.0rc0-268-g09a04829)
Copyright 1998-2019 Gerald Combs gerald@wireshark.org and contributors. License GPLv2+: GNU GPL version 2 or later http://www.gnu.org/licenses/old-licenses/gpl-2.0.html This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with libpcap, without POSIX capabilities, without libnl, with GLib 2.48.2, with zlib 1.2.8, without SMI, without c-ares, without Lua, with GnuTLS 3.4.10 and PKCS #11 (closed) support, with Gcrypt 1.6.5, without Kerberos, without MaxMind DB resolver, without nghttp2, without LZ4, without Snappy, without libxml2.
Running on Linux 4.15.0-122-generic, with Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz (with SSE4.2), with 7394 MB of physical memory, with locale en_CA.UTF-8, with libpcap version 1.7.4, with GnuTLS 3.4.10, with Gcrypt 1.6.5, with zlib 1.2.8, binary plugins supported (0 loaded).
Built using gcc 5.4.0 20160609.