On Mar 25, 2018, at 11:35 AM, Paul Offord wrote:
> I have real dissector code that builds a protocol tree and so I guess this
> falls under libwireshark.
Yes.
> However, I also have two block read functions that are registered like this:
>
>
19:11
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
Subject: Re: [Wireshark-dev] allocator->in_scope
On Mar 25, 2018, at 10:39 AM, Paul Offord <paul.off...@advance7.com> wrote:
> Even bigger aha. Although I only have one new block in the pcapng file, whe
On Mar 25, 2018, at 10:39 AM, Paul Offord wrote:
> Even bigger aha. Although I only have one new block in the pcapng file, when
> I open the file via the file explorer dialogue, my block reader is called
> twice; once to allow WS to enrich the dialogue box (I think)
t list for Wireshark <wireshark-dev@wireshark.org>
Subject: Re: [Wireshark-dev] allocator->in_scope
Aha - whilst what I've written below is true, it doesn't accurately reflect the
issue.
If I start Wireshark and double click on a file in the recently opened list,
part of the processing is t
Hi Paul, that’s an interesting case you’ve found. The file scope was
definitely intended for file-scoped dissection memory (which is why it is
enabled in init_dissection() and not earlier in the file lifecycle) but I
can definitely see the use for it in writing a block reader too.
I think it is
Aha - whilst what I've written below is true, it doesn't accurately reflect the
issue.
If I start Wireshark and double click on a file in the recently opened list,
part of the processing is this:
cf_open() calls
ws_epan_new() calls
epan_new() calls
init_dissection() calls
Hi,
Still working on my new block reader. To recap, I've defined a new pcapng
block type and written a dissector. The first thing I have to do is read the
new block type, and Wireshark provides a framework to do this. In the new
block reader I define some space like this: