On May 16, 2016, at 11:24 AM, Michael Mann <[email protected]> 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 <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
