[pcap-ng-format] Adding more options to the specification

[Guy Harris]

On May 10, 2012, at 12:50 AM, Jasper Bongertz wrote:

>   My question is this: there are already optional fields in most block types,
>   and I wonder if it is still possible to add one or two more without breaking
>   support in Wireshark?

That particular question is best asked on the wireshark-dev mailing list.  This list is, I think, intended for discussion of the file format, rather than of particular code that reads or writes the format.

Your subsequent questions are the ones

>   As far as I understand the specifications it SHOULD be
>   possible, since an option is to be ignored if not understood.

Yes, Wireshark and libpcap will both ignore unknown options.  (Note that "will ignore" implies "will not preserve if you use the software in question to process the file".)  I can't speak for arbitrary code that reads pcap-ng files, but one would hope that the developers of that code won't screw up and make it fail if it encounters unknown options.

>   For example: I'd like to add an text option to the SHB to write down what
>   program did the capture. There is already an option called "shb_userappl",
>   but that is the application name that wrote the section. If (like it is in my
>   case) I want to write a pcap-ng file with my own tool, I'd use that option to
>   specify my own application name, loosing the original one written by dumpcap
>   (or whatever capture program really wrote the capture in the first place). So
>   maybe we can add an option called "shb_captureappl" that can be used to write
>   down what capture process originally captured the file?

This is arguably a bigger issue - a capture file can be created by version A1 of application A, read and processed by version A2 of that application, further read and processed by version B1 of application B, and so on.  Perhaps, for example, pcap-ng should support multiple shb_userappl options, and specify that each application that writes the file should add a new shb_userappl option after the existing ones.

>   Also, for EPB's I'd like to add an option called "epb_history" (also a text
>   option) that can be used to track changes to a packet. For example "IP
>   address anonymized" or something like that. There is a comment field, but I
>   feel that it should not be abused for change tracking because it is reserved
>   for users to take notes about packets. The format of the history might be
>   something like "change1","change2","change3"... so that there can be multiple
>   changes separated by comma and enclosed in quotation marks, with the latest
>   change at the end of the list.

Perhaps that's another case where multiple instances of the option should be used, rather than having the option be a comma-separated list of changes.

>   Third (and last): can we assign block types to compression and encryption
>   blocks, or is there a reason why they do not have any?

I assume that it's because they're not official block types, but proposals for block types, put forth for further investigation.