Wireshark mailing list archives
Re: PCAP-NG metadata support
From: Guy Harris <guy () alum mit edu>
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. ___________________________________________________________________________ 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
Current thread:
- PCAP-NG metadata support Carpenter, Brandon J (Jul 20)
- Re: PCAP-NG metadata support Martin Kaiser (Jul 20)
- Re: PCAP-NG metadata support Stephen Donnelly (Jul 23)
- Re: PCAP-NG metadata support Guy Harris (Jul 23)