[pcap-ng-format] Reading and writing blocks you don't understand

[Guy Harris]

On Jul 19, 2014, at 3:55 PM, Michael Richardson <mcr at sandelman.ca> wrote:

> Michael Tuexen <tuexen at wireshark.org> wrote:
>>> If you have a pcap-ng file with a section with a given endianness, and
>>> a program that reads a pcap-ng file, processes it in some fashion, and
>>> writes out a new file, what should that program do with blocks that it
>>> doesn't understand?
> 
>> This is an interesting question... What about using some bits in the
>> block type to indicate what should be done. Basically one bit could
>> mean: * stop processing of the file or continue when reading Another
>> one could mean: * drop when writing or just copy it out.
> 
> Yes, have a critical bit in the option space.

By "critical bit" do you mean "if you can't understand this block, you can't understand the file", so that if you're reading the file and see a block with that bit set, you have to stop processing the file"?  An IDB would be such a block, as you can't interpret packet blocks without knowing the link-layer header type for the interface for the packet, and one might consider packet blocks to be critical, too, as there's not much to analyzer if you can't read a packet block. :-)

Ideally, we wouldn't introduce those, as that'd mean there'd be pcap-ng files that no old software could read, even with a loss of information.

In some sense, adding such a block would mean you've bumped the minor version number; however, using the minor version number in that fashion means you'd want to set the minor version number based on whether you're going to write out a block of that type or not, which might require going back and fixing the version number afterwards if you can't determine that ahead of time - and a program that can write to a pipe can't go back and fix the version number afterwards.

So if we think there could be blocks of that sort, that'd be a reason for that bit.