[pcap-ng-format] Addition of new content

[Guy Harris]

On Sep 3, 2015, at 5:21 PM, Michael Haney <michael-haney at utulsa.edu> wrote:

> BTW (I know this isn't the best place to report a bug, but it speaks to the extensibility issue) capinfos is a great too for reading pcapng files and summarizing them because it appropriately skips well-formed blocks and block options it doesn't understand and if anything is off, it says the file is corrupted.  Very handy for development.  But if you change the "pcapng version" major and minor from anything other than 1.0, it says the file is corrupt.

"Corrupt"?  OK, that's definitely a bug...

...it should say "unsupported" instead.

But are you sure it said the file was corrupted, rather than saying something such as

	File contains record data we don't support
	(pcapng_read_section_header_block: unknown SHB version 1.1)

which doesn't contain the word "corrupted", it says "we don't support" and "unknown SHB version"?

> I would like to be able to tinker with pcapng blocks and call it "1.1" in the file...

Any change to the minor version number should be done *only* if

	1) code that can read 1.1 files can read 1.0 files with the exact same code path that reads 1.1 files;

	2) code that can read 1.0 files but that has not been changed to read 1.1 files *cannot* read 1.1 files because the file cannot be understood without understanding the new blocks/options.

For example, if we were to introduce a new variant of the IDB with a time stamp (not as an option, but as a fixed part of the block) giving the time capturing started on the interface, such that a file can describe an interface either with the existing IDB or with a new-format IDB, that would mean that a file using only new-format IDBs could *not* be handled by code that only knows about the old-format IDB, as it wouldn't have any IDBs it understands for any of the packets in the file.  However, code that can handle either IDB type could still read a file with the old-format IDB, so that would be a case where the minor version number would be increased.

Adding some new block type that just gives more information that's useful but not necessary in order to understand the other blocks would *not* cause the minor version to be changed.

So, to justify calling the file version 1.1, your tinkering would have to break the ability of existing code to read files, in which case it'd be quite appropriate for that code to report it as unsupported.

(A change to the *major* version would happen if code that wanted to read 1.x and 2.x code would have to use different code paths, e.g. a change to the format of the fixed portion of the SHB would require that the major version number be changed.)