-----Original Message-----
From: Guy Harris <guy@xxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Sun, May 15, 2016 10:17 pm
Subject: Re: [Wireshark-dev] Some questions about the "option block" interface in libwiretap
On May 15, 2016, at 6:40 PM, Guy Harris <
guy@xxxxxxxxxxxx> wrote:
> 1) What is an "option block"? No capture file format we read has anything called an "option block"; in pcapng, a file is a sequence of blocks, each of which can have zero or more options. Is an "option block" really just a "block" - or what other parts of libwiretap call a "record"?/
I guess the closest explanation is a "block with options" (suggestions on other names certainly welcome). It is heavily influenced by pcapng functionality but was intended to be generic for all file types, so maybe "record" could apply. Block, record, blob - any other generic term we want to try to apply?
The idea is based off of
https://code.wireshark.org/review/9729 which wanted to add support for "custom options" in a block. I just took it a step farther and thought all option(al) fields in a block could be made more generic. I wanted to get away from the "rigid" structures in wtap.h and I thought this approach could better help future/backwards compatibility when either more options are defined or some of the yet to be used (pcapng) options start being used.
>
> 2) In the pcapng specification, nothing prevents a block from having multiple comment options; can the "option block" interface handle that?
No, it can't yet, partially because the code it refactored didn't support it at the time.
>
> 3) What mechanisms are available for handling block/record types, or options, not currently supported by pcapng, but that might be provided by other file types? Hadriel Kaplan suggested getting a Private Enterprise Number (PEN) for wireshark.org, and using custom blocks and options for this purpose; have we gotten a PEN for wireshark.org yet?
The current interface may need another layer of refactoring but the idea was that you would have a block and just call wtap_optionblock_add_option to add your options. For "defined but not yet used" options of the standard blocks that turn into "now used" options, the wtap_optionblock_add_option would be done within the creation of that standard block. The creation of "standard blocks" and their option types is where we may need another layer of registration and refactoring. Copying/reading/writing on any/all blocks is supposed to happen within the "option block" functionality (where default behavior would be "inclusive" in copying blocks). I wasn't sure where "merging" would go and if that would be part of the "option block" functionality (at least for "provided" blocks/options) or left to external tools (like mergecap and editcap).
I have no idea about PEN status.
>
> 4) The existence of wtap_file_get_shb() seems to imply that a file has *a* Section Header Block, but a pcapng file could have multiple SHBs; we don't currently support that, but we should be prepared to do so in the future.
>
> A file can also have multiple Name Resolution Blocks as well; as the pcapng specification says:
>
> Multiple NRBs can exist in a pcapng file, either due to memory constraints or because additional name resolutions were performed by file processing tools, like network analyzers.
>
> so we should not have routines that assume a single NRB. Perhaps the routines in question should take an array of NRBs - combining the NRBs into a single table would lose information about which names were resolved by which name servers.
This was another reason to not have structure members specifically called out for different block types. We can just store an "array of blocks" and adjust APIs accordingly.
