I've been helping Alastair debug this problem and this is as far as we got. I can only think of a race condition between dumpcap completing the packet writing to the file and tshark being able to read the expected number of new packets.
I do see there is fflush() in capture_loop_write_pcapng_cb() before the capture_loop_wrote_one_packet() which actually increments the number of available packets. Do we also need an fsync() here to ensure the data is written to the disk? James On Mon, Nov 16, 2020 at 12:47 PM Alastair Scott <a...@exegin.com> wrote: > Hi all, > > 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. > > The bug occurs when calling the command "tshark -i TCP@127.0.0.1:19000" > from the command line. 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. This usually happens at least once every 20 to 30 attempts. > > Is it possible there could be some timing problem with writes to the > /tmp/wireshark_*****.pcapng file in dumpcap getting flushed and then > reading from tshark? If not, what are some other possible reasons this > could be occuring? > > I've posted an in-depth description of the issue with logs and pcap's > attached here: https://gitlab.com/wireshark/wireshark/-/issues/17013 > > Regards, > > Alastair > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
