Re: PCAP-NG metadata support

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

On Jul 20, 2012, at 10:15 AM, Carpenter, Brandon J wrote:

> I've been working on a patch to overcome one of Wireshark's limitations 
> with regard to PCAP-NG captures.  The patch adds metadata (section, 
> interface, packet options, etc) to the dissector window and allows one 
> to filter packets based on the metadata.

Presumably you're referring to metadata *other* than packet comments, as those *are* shown in the dissector window in 
1.8.0 and later and you *can* filter based on packet comments, e.g.

        comment contains "abnormal delay"

The SHB metadata currently specified in the pcap-NG spec is:

        per-file comments;

        hardware description string;

        OS description string;

        application description string.

They're shown in the Statistics -> Summary window; I'm not sure where they'd be shown in the main window, as they're 
not per-packet.  Presumably filtering on them would be useful if you had a multi-section capture if, for example, 
multiple pcap-NG captures were concatenated together.

For interface metadata, some of that might be best put in the interface list in the Statistics -> Summary window.  The 
interface *name* arguably belongs in the "Frame" section of the packet details - the interface *ID* doesn't really tell 
you very much - which would require that epan_dissect_new() take the interface information as an argument, as 
libwireshark does *not* assume the packets are coming from a capture file being read with libwiretap.

For additional packet metadata, that belongs in the Frame section of the protocol tree - and should be supported for 
other capture file formats as well.

> Along with being able to view the metadata, the patch is also working 
> toward a plugin approach for parsing new PCAP-NG block types and 
> options.  Ideally, I think it would be nice to allow writing custom 
> block and option parsers in the dissectors that display them.  Any ideas 
> on how to best accomplish this?

Well, one way to do it might be to have wtap_read() supply not packets but blocks, with "packet" being one type of 
block.  It shouldn't supply *raw* pcap-NG, because libwiretap is intended to be an abstract interface supporting 
multiple capture file types, and some file formats may have capabilities not supported by pcap-NG (and even if we add 
equivalent capabilities to pcap-NG, the *next* file format for which somebody adds support might provide yet *another* 
capability that pcap-NG doesn't have).

So, for example, there's no need to have code using libwiretap care about Simple Packet Blocks vs. Packet Blocks vs. 
Enhanced Packet Blocks - all three of them should be mapped to "packet" by the pcap-NG module in the library (as is 
already done; one of the items supplied for a packet is a flags field, which includes a flag indicating whether a time 
stamp is present, and there are modules other than pcap-NG that use that flag, such as the modules that handle 
non-packet-capture file formats).

My inclination would be to:

        have a set of block types returned by wtap_read();

        have a dissector table for block types, with the "frame" dissector registering for the "packet" frame type;

        have one of the block types be "unknown pcap-NG block type", with the entire contents of the block supplied to 
the dissector as a blob of data;

        have the dissector for that block type have a dissector table for pcap-NG block types, with custom block type 
parsers registering for that.

As for custom *option* parsers, most options are specific to particular block types.  For pcap-NG blocks that don't 
correspond to any "known" libwiretap block type, the options would obviously be parsed by the dissector for that 
pcap-NG block type; it would be up to that dissector to handle options itself or have a dissector table for option 
types.  For pcap-NG blocks that *do* correspond to "known" libwiretap block types - and note that this set could expand 
over time, if we decide to make a libwiretap block type that handles them as well as some other format's blocks that 
have similar-enough semantics - we'd have to come up with some way to handle block metadata in an expandable fashion.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe