Comment # 10
on bug 1650
from [email protected]
(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. Thanks
You are receiving this mail because:
- You are the assignee for the bug.
- You are watching all bug changes.