On Fri, Feb 3, 2023 at 7:05 AM Guy Harris <ghar...@sonic.net> wrote: > 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. >
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.
___________________________________________________________________________ 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
