Thanks for the advice (and note from Evan).
I haven't even begun to consider things like capinfos, mergecap, tshark, etc.
I guess now is the time to think about these things.
So just to clarify things here:
I have real dissector code that builds a protocol tree and so I guess this
falls under libwireshark. However, I also have two block read functions that
are registered like this:
register_pcapng_block_type_handler((guint)BLOCK_TYPE_TDB, tdb_read_block,
NULL);
register_pcapng_block_type_handler((guint)BLOCK_TYPE_TRB, trb_read_block,
NULL);
Are my block read functions part of libwiretap?
I'm just wondering if I should split the code that reads the new blocks and the
code that does the dissection. It's not going to be easy.
-----Original Message-----
From: Wireshark-dev <[email protected]> On Behalf Of Guy
Harris
Sent: 25 March 2018 19:11
To: Developer support list for Wireshark <[email protected]>
Subject: Re: [Wireshark-dev] allocator->in_scope
On Mar 25, 2018, at 10:39 AM, Paul Offord <[email protected]> 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) and a second
> time to read the block before dissection. I never noticed this before, and
> this probably explains a few weird problems I have been grappling with.
What happens if you run the capinfos program on your file?
If your block reader is called in that case, then it cannot use the wmem
allocators, as 1) the wmem routines are part of libwireshark and 2) capinfos
doesn't use libwireshark. The code to put the summary in the dialog box is
similar to the capinfos call, in that it doesn't do any dissection, it just
gets what statistics can be gathered without looking at the contents of any of
the records, just the metadata at which libwiretap looks.
Your block *dissector* can use the wmem routines, as dissectors are part of
libwireshark or are plugins that "belong to" libwireshark; code that is part of
libwiretap or that is a plugin that "belongs to" libwiretap, however, cannot
use the wmem routines.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
______________________________________________________________________
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
Any views or opinions expressed are solely those of the author and do not
necessarily represent those of Advance Seven Ltd. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or omissions in the
contents of this message, which arise as a result of e-mail transmission.
Advance Seven Ltd. Registered in England & Wales numbered 2373877 at Endeavour
House, Coopers End Lane, Stansted, Essex CM24 1SJ
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
