Wireshark · Wireshark-dev: Re: [Wireshark-dev] PCAP-NG metadata support

[Guy Harris <guy@xxxxxxxxxxxx>]

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.