Wireshark-dev: Re: [Wireshark-dev] PCAP-NG metadata support
From: Guy Harris <[email protected]>
Date: Mon, 23 Jul 2012 16:12:21 -0700
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.
- [Wireshark-dev] PCAP-NG metadata support
- From: Carpenter, Brandon J
- [Wireshark-dev] PCAP-NG metadata support