Wireshark-bugs: [Wireshark-bugs] [Bug 1650] When selecting "use multiple files", file error occu
Comment # 11
on bug 1650
from Jeff Morriss
(In reply to comment #10)
> (In reply to comment #3)
> > When I was looking through how dumpcap works with Wireshark/tshark I
> > wondered if something like this would be possible or not.
> >
> > The basic question is: how can dumpcap be sure, when moving to the next file
> > in a ring buffer (and especially when deleting an old ringbuffer file), that
> > Wireshark is currently working on the same file dumpcap is. In other words,
> > it's possible that dumpcap could advance through several files before
> > Wireshark has finished processing the first one. In a ring-buffer situation
> > (such as this bug) dumpcap could erase, say, the 2nd generated file before
> > Wireshark gets to it. When Wireshark *does* get to it, you get the quoted
> > error. Of course this would only happen at high data rates or if Wireshark
> > is really slow (busy doing DNS lookups, for example).
> >
> > Not sure what to do about that...
>
> Hi, sorry for asking about this again but it has been 6 years since this
> comment, so, now are you sure that the reason of this problem is the
> difference of processing speed between Dumpcap and *shark? Because, if so,
> it always cause a delay of incoming data to be dissected and the delay
> increase as time goes by. But it is not really true in my case, when I send
> my data to dumpcap and immediately see it going out from Dissectors as can
> be seen in the log. No delay even I let tshark run in 2 days before testing.
> i also use buffer ring but I set filesize large enough to be non-stop. I
> really don't understand. I just need a confirmation to understand clearly.
I'm pretty sure that's the problem. In my testing yesterday every time I got
the error, for example, saying that the file "/tmp/foo_00008<whatever>" could
not be opened and tshark quit if I did "ls -l /tmp/foo*" I would see a bunch of
files starting with, for example, "foo_00009" or "foo_00010". That, to me,
means that dumpcap had rotated off the 00008 file before tshark got to it.
Note that it's highly likely that *shark's processing speed will vary
(especially if you're using synchronous name lookups) whereas the speed with
which dumpcap rotates files depends pretty much only on the speed that the
packets come in and the speed with which it can write the files out.
You are receiving this mail because:
- You are the assignee for the bug.
- You are watching all bug changes.
