Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Adding name resolution blocks in Wireshark

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Wed, 8 Feb 2012 14:23:59 -0800
On Feb 8, 2012, at 12:33 PM, Anders Broman wrote:

> Guy Harris skrev 2012-02-08 21:20:
>> On Feb 8, 2012, at 8:05 AM, Anders Broman wrote:
>> 
>>> Should it be safeguarded with a preference?
>> No.  Older versions of Wireshark will ignore name resolution blocks, as does libpcap and hence all programs using libpcap to read pcap-ng files.
> I was more thinking along the lines that you might not want to save it.

For privacy reasons?

Are there situations where you don't mind sending somebody a capture file with IP and MAC addresses from your network but you would mind sending them a capture file with that *and* an address-to-host-name mapping?  If not, perhaps anonymizers need to strip NRBs from pcap-ng files (note that any anonymizer that uses libpcap will automatically remove NRBs, because the libpcap code to read a pcap-ng file ignores NRBs, and the code to write the capture file out only writes pcap format in any case).

> On the subject of pcapng features should the structs defined in pcang.c (wtapng_block_t and friends)
> be moved to wtap-int.h and included in the wtap structure to get at things like interface id and info.

I don't think the point in a capture stream where an Interface Description Block appears is significant beyond the IDB having to appear before the first packet block for that interface, so storing interface information in the wtap structure (which includes "pointed to by the wtap structure") would probably work.

The same doesn't apply to the Interface Statistics Block, so in order to support *that* we'd want to have a way for wtap_read(), or a replacement for it, indicate an ISB rather than a packet block, or attach them to the wtap structure along with an indication which packet an ISB followed (there's no guarantee that it precedes any packet, as it can appear at the end; I guess it could, in principle, come at the beginning of the file, but then it follows "packet 0").

All the other block types are experimental, and some aren't sufficiently fully described to even determine what a program would do with them.