Re: Some questions about the "option block" interface in libwiretap

[Michael Mann <mmann78 () netscape net>]

-----Original Message-----
From: Guy Harris <guy () alum mit edu>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
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 () alum mit edu> 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.


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe