Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Tshark closing unexpectedly due to failure reading from file

From: John Sullivan <jsethdev@xxxxxxxxxxxxxx>
Date: Thu, 19 Nov 2020 14:13:14 +0000
On Monday, November 16, 2020, 8:45:48 PM, Alastair Scott wrote:
> I've posted an in-depth description of the issue with logs and pcap's
> attached here: https://gitlab.com/wireshark/wireshark/-/issues/17013

Observations after running under strace with "-f -s 4096" with the
same capture file (5992 bytes, SHA1 cefbb7):

* tshark execs dumpcap to do the actual "capture" and communicates
with it over pipes and a temporary file

* Given we're reading from a pcapng file, despite the convoluted data
path, dumpcap's output to the temp file is actually identical to the
original pcap file (same size, same sha1sum). This is written out in what
looks like packet-sized chunks as it reads them from the socket.

* The reading end does three read() calls. The first two between them
read the first 4096 bytes, the third reads the remaining 1896 bytes.
The first happens almost immediately after opening the file, the
second two not until the writing end has finished writing all data
(which it signals by writing the packet count over the pipe). This is
the same between failing and successful runs.

* By extracting the data from strace output I can prove that the
reading end does in fact read all data, and exactly the same data as
in the original file, even in the failing case. There is no problem
there.

* One key difference appears to be that in the failing case the first
read happens before the writing end has written anything at all, and
reads 0 bytes. The second read then reads 4096 bytes, and the third
1896 bytes, before the reading end throws that all away and aborts. In
the successful case the first read happens late enough to return 28
bytes, then the second reads asks for (and gets) only 4068 bytes to
make up the difference to 4096 bytes.

So it looks like a race at the beginning, and even though the complete
data transfer is executed in all cases, if that initial read didn't
get the first valid file chunk so the "section header block" can be
validated, then it will ultimately cause the file to be rejected.

John
-- 
Dead stars still burn