Wireshark mailing list archives
Re: Tshark closing unexpectedly due to failure reading from file
From: John Sullivan <jsethdev () kanargh org uk>
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 ___________________________________________________________________________ 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-request () wireshark org?subject=unsubscribe
Current thread:
- Tshark closing unexpectedly due to failure reading from file Alastair Scott (Nov 16)
- Re: Tshark closing unexpectedly due to failure reading from file James Ko (Nov 18)
- Re: Tshark closing unexpectedly due to failure reading from file Guy Harris (Nov 18)
- Re: Tshark closing unexpectedly due to failure reading from file James Ko (Nov 19)
- Re: Tshark closing unexpectedly due to failure reading from file Graham Bloice (Nov 19)
- Re: Tshark closing unexpectedly due to failure reading from file James Ko (Nov 19)
- Re: Tshark closing unexpectedly due to failure reading from file Guy Harris (Nov 19)
- Re: Tshark closing unexpectedly due to failure reading from file Guy Harris (Nov 18)
- Re: Tshark closing unexpectedly due to failure reading from file James Ko (Nov 18)
- Re: Tshark closing unexpectedly due to failure reading from file James Ko (Nov 19)
- Re: Tshark closing unexpectedly due to failure reading from file John Sullivan (Nov 19)
- Re: Tshark closing unexpectedly due to failure reading from file Alastair Scott (Nov 19)
- Re: Tshark closing unexpectedly due to failure reading from file Guy Harris (Nov 20)
- Re: Tshark closing unexpectedly due to failure reading from file James Ko (Nov 20)
- Re: Tshark closing unexpectedly due to failure reading from file Guy Harris (Nov 20)
- Re: Tshark closing unexpectedly due to failure reading from file Alastair Scott (Nov 20)