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 <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
