Good thought. I've only tried on my laptop. I'll let Alastair answer about his setup. I think we both using Lenovo laptops with SSDs?
I know another colleague has seen similar failures with tshark on a TCP stream as well. I can't say that I've ever seen this fail when using wireshark however. We have reproduced it using different pcapng TCP stream sources. We have reproduced it with or without tshark filters. James On Thu, Nov 19, 2020 at 12:46 AM Graham Bloice <graham.blo...@trihedral.com> wrote: > Have you been able to replicate the issue on another system to rule out a > local environmental problem? > > On Thu, 19 Nov 2020 at 08:37, James Ko <j...@exegin.com> wrote: > >> @Guy. This is on ubuntu linux distribution. I'm using Xubuntu 18.04LTS >> and I believe Alastair is on Ubuntu 16.04LTS. >> Assuming the buffer/page/disk cache is not doing the right thing is there >> anything we can try to make sure it's consistent? >> >> @Jaap. We will be sure to update to the latest release but I don't >> expect this will make much difference as the dumpcap/tshark interface has >> been around for years. >> >> James >> >> On Wed, Nov 18, 2020 at 9:22 PM Guy Harris <ghar...@sonic.net> wrote: >> >>> On Nov 18, 2020, at 4:25 PM, James Ko <j...@exegin.com> wrote: >>> >>> > 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? >>> >>> If this is on UN*X, that would be an issue only if your UN*X is really >>> stupid about managing the buffer/page cache. I know of no UN*Xes where >>> that's the case. >>> >>> If this is on Windows, I *still* wouldn't expect it to be the case, at >>> least on any Windows NT-based version (and we haven't supported Windos >>> 95/98/Me for a long while, and neither has Microsoft...), as I think it has >>> the same sort of buffer/page cache as most if not all UN*Xes these days >>> have. >>> >>> I.e., if process A is writing to a file, and process B is reading from a >>> file, process B's write should immediately update the buffer/page cache, so >>> process B's read should see it, as long as the read is done after the write. >>> >>> flush() just means "do a write to the underlying file immediately"; it >>> doesn't imply anything more than write() on UN*X or _write() on Windows >>> (which, in turn, turns into a WriteFile() if you're writing in binary >>> mode), so it updates the buffer cache but doesn't necessarily update the >>> file on secondary storage. mailto: >>> wireshark-dev-requ...@wireshark.org?subject=unsubscribe >>> >> > > -- > Graham Bloice > ___________________________________________________________________________ > 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
