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

[Guy Harris <guy () alum mit edu>]

On May 16, 2016, at 11:24 AM, Michael Mann <mmann78 () netscape net> wrote:

> Not if we can get then into 2.2 in time.

I am not convinced that all the stuff that really should be done to libwiretap can be done by the North America 
Sharkfest, so that would happen only if we delay the 2.2 release.

For example, we currently don't handle packet metadata very cleanly.  We have a bunch of WTAP_ENCAP_ values that 
correspond to a regular encapsulation plus file-type-specific metadata.

It might be possible to have them indicated separately, so that you'd have, instead of WTAP_ENCAP_NETTL_ETHERNET, 
WTAP_METADATA_NETTL plus WTAP_ENCAP_ETHERNET.  That would, for example, make it easier to convert a nettl Ethernet 
capture into a regular Ethernet capture.

We might also have libwiretap do the work of constructing generic 802.11 radio information from radiotap, so that the 
radiotap dissector doesn't have to, and so that we could perhaps convert between different 802.11+radio data formats.

In addition, the metadata that doesn't come directly from the packet data should probably be put into a Buffer rather 
than a union as is done now; that way we don't have a hard upper limit on the amount of metadata (the ERF handler 
imposes a limit, about which Anthony Coddington of Endace has commented).

And I think there are still some issues with mergecap that would require better handling of IDBs...

...and we need to think about whether we're correctly handling all of:

        files that have a per-file link-layer header type (most file formats, including pcap);

        files that have per-interface link-layer header types (such as pcapng);

        files that have per-packet link-layer header types.

We should also check to make sure we can handle plugins for pcapng block types as well as pcapng option types; pcapng.c 
has a plugin mechanism for both, but we need to make sure it could, for example, handle the Hone blocks and options, 
including handling them in mergecap (which might require that there be plugin support in the merge mechanism in 
libwiretap).

So I'm not convinced that we're close to being "done" with libwiretap, or that we'll be "done" in a month, and would 
strongly be opposed to declaring the 2.2 version of libwiretap as the "final" version, to which we can make no 
incompatible changes.
___________________________________________________________________________
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