[Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx>]

On Fri, Feb 3, 2023 at 7:05 AM Guy Harris <gharris@xxxxxxxxx> wrote:

On Jan 28, 2023, at 3:19 PM, Martin Mathieson via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:

> I have 5 non-standardised/local block types that are in-use within my company, that are in the 'local' range  0x80000000-0xFFFFFFFF.
>
> My first thought was to add a dissector table (pcapng.block-types ?) by 'Block Type Code' in file-pcapng.c, then have dissectors register by adding themselves to the table.
>
> However, looking at the dissector code, it appears that just registering a dissector would not work well, and that there are several points where file-pcapng needs to reference block-type-specific information:
>
> - a name to show for the block (currently fixed vals[] for standard block types)

That's a problem not unique to pcapng blocks.

There exists a next-protocol type field for which we have a dissector table, named "ethertype", but a dissector registering itself in that table can't also add an entry to the etype_vals[] table.

It might be nice to have a mechanism to solve that in general.

However...

> - a callback function for handling the body of the block type
> - options handling (another dissector callback and maybe vals[] ?)

...those are specific to pcapng block types.  There are other cases a protocol offers its own registration routine to allow sub dissectors to register more than just a dissector, e.g. rpc_init_prog() for ONC RPC and dcerpc_init_uuid() for DCE RPC.  It's harder to generalize that in a "static" (compile-time) fashion; it'd either involve:

        passing a generic pointer, where the parent and child dissector agree on the type of structure to which that generic pointer points;

        adding parent-dissectors-specific registration routines to the API (as is the case with, for example, ONC RPC and DCE RPC - I think there are other examples);

        passing a key-value store, which is somewhat like the generic pointer, except that there came be some run-time checking done by the callee.

So, for now:

> So maybe the dissector for these types could register this information (per block id) in its handoff function, and file-pcapng.c would look up a table when handling entries in the 'local' range.

...perhaps the second solution would be the right one, at least for now, with the handoff function calling pcapng's "register a local block type" routine.

Yes, my plan is to add a registration function along the lines of:

register_pcap_local_block_dissector(block_num,  block_name, main_data_callback, [option_hf], [option_vals], [option_data_callback]);

 

And store it in a table mapping from block_id --> <struct with fields above>

 

> I do notice handling for BLOCK_DARWIN_PROCESS (0x80000001) is already built-in to file-pcapng.c...

Whatever mechanism we use should also support moving Apple's process info block out of file-pcapng.c as well.

Yes.  I will move my private dissector into this format too.  I have yet to look for a capture DARWIN PROCESS blocks in it.