Thanks Guy! I tested your fix myself and it solved my problem.
Regards,
Alastair
On Fri, Nov 20, 2020 at 12:37 AM Guy Harris wrote:
> On Nov 19, 2020, at 9:07 PM, Alastair Scott wrote:
>
> > Do you know where in the code base I could look for a potential remedy
> to this issue? I'm trying to
On Nov 20, 2020, at 1:18 AM, James Ko wrote:
> I just have one question about the fix.. Is it okay to send multiple SP_FILE
> indications on the same file?
No.
The current version of the merge request only sends one.
> If the pcapng stream inserts a new SHB to start a new section does dumpcap
Thanks Guy.
That was my analysis since my last email as well. I just hadn't come up
with a fix. ;-)
I just have one question about the fix.. Is it okay to send multiple
SP_FILE indications on the same file?
If the pcapng stream inserts a new SHB to start a new section does dumpcap
restart with a
On Nov 19, 2020, at 9:07 PM, Alastair Scott wrote:
> Do you know where in the code base I could look for a potential remedy to
> this issue? I'm trying to find a place to add a delay to ensure the read does
> not come early.
What needs to be delayed is the sending of the SP_FILE message from d
Hi John,
Do you know where in the code base I could look for a potential remedy to
this issue? I'm trying to find a place to add a delay to ensure the read
does not come early.
Regards,
Alastair
On Thu, Nov 19, 2020 at 6:15 PM John Sullivan
wrote:
>
> [gitlab page updated with details]
>
> On
[gitlab page updated with details]
On Friday, November 20, 2020, 12:15:11 AM, James Ko wrote:
> Why do we have the difference in read/write timing?
Umm, because you just would, unless the reader and writer end take
specific measures to avoid that, which they apparently don't. (Note
that it looks
Hi John,
Thanks for your analysis. If you still have the strace logs would you
attach them to the bug report together with your analysis?
So I think the questions now are..
Why do we have the difference in read/write timing?
What are the events that need to happen before the first bytes are writ
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
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
It might be helpful to specify -f to your strace, as that would
capture tshark's interactio
On Nov 19, 2020, at 12:37 AM, James Ko 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
I would not make that assumption; as I said, "If this is on
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 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 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/pa
@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
Hi,
From the issue report I saw that you’re using some development version “TShark
(Wireshark) 3.1.0 (v3.1.0rc0-268-g09a04829)”. Can’t say it makes a difference
in this case, but this is not recommended. If you could update to the latest
3.2, or 3.4 release that would at least give us some stab
On Nov 18, 2020, at 4:25 PM, James Ko 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'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()
Hi all,
I'm experiencing an issue where tshark is stopping unexpectedly. I have a
process streaming pcapng data over a TCP socket to tshark and using
tshark's TCP@ interface type on the command line. Most of the time
everything will be fine but every now and then tshark will stop right away
and pr
17 matches
Mail list logo
