On Jan 28, 2023, at 3:19 PM, Martin Mathieson via Wireshark-dev
<wireshark-dev@wireshark.org> 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.
> 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.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
