Wireshark-dev: Re: [Wireshark-dev] Some questions about the "option block" interface in libwire
On May 16, 2016, at 11:24 AM, Michael Mann <mmann78@xxxxxxxxxxxx> 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.
