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

[Anders Broman]

-----Original Message-----
From: pcap-ng-format-bounces at winpcap.org [mailto:pcap-ng-format-bounces at winpcap.org] On Behalf Of Jasper Bongertz
Sent: den 11 maj 2012 14:48
To: pcap-ng-format at winpcap.org
Subject: Re: [pcap-ng-format] Adding more options to the specification

On 10.05.2012 19:47, Guy Harris wrote:
>> 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.
>
>Yes, correct, I was just carefully starting my topic with what I assume, just to be sure :-)
>
>> 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.
>Agree. We cannot expect arbitrary software to preserve options they do not understand when reading a pcap-ng file, so those options will most likely be discarded >when writing to a different file after processing.

>
>>   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.
>
>Okay, that would be possible - but am I looking at this the wrong way when I assume that the initial capture process is always done by a single application? What >I want to do is to preserve what application did the initial capture to be able to deduct the quality of the capture from what I know about the application, and 
>that is usually the application that took the frames from the medium and wrote it to file in the first place. Of course it would also be nice to keep track of 
>what applications read and write the file afterwards, so I guess we could go with multiple shb_userappl options. Maybe in that case we just need to mention in the >format specifications that there maybe a chaining of shb_userappl options containing that kind of history.

Would it be better to have a (file)history block and let the SHB reflect the original capture?


>
>>   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.

You're right, that's probably a better solution than having a substructure in an option.
>
>>   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.
Wouldn't further investigation need a block type first so that it can be tested? On the other hand... a test implementation could probably just use any free block type number and change it later to whatever ends up in the specification (if at all).


_______________________________________________
pcap-ng-format mailing list
pcap-ng-format at winpcap.org
https://www.winpcap.org/mailman/listinfo/pcap-ng-format