[pcap-ng-format] Addition of new content

[Michael Haney]

On Thu, Sep 3, 2015 at 7:10 PM, Guy Harris <guy at alum.mit.edu> wrote:

>
> 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"?
>

You are correct.  The exact output I get from "file" and from "capinfos" is
this (having created a file with minor version 0x0002):

> file network-tap.pcapng
network-tap.pcapng: pcap-ng capture file - version 1.2

> capinfos network-tap.pcapng
capinfos: Can't open network-tap.pcapng: The file isn't a capture file in a
known format

My apologies for flippantly using the word "corrupt" without
double-checking my memory.  In my "tinkering" I definitely created many
files reported as corrupt - because they were.



> > 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.
>
>
I see your point. My confusion came from the idea that any
pcapng-compatible code should be built to skip over blocks it doesn't
understand, and that unknown additional blocks can safely be skipped.  In
my mind, adding additional blocks, while keeping all the v1.0 blocks
well-formed, should be indicated by some kind of version change but not
necessarily stop a tool in its tracks.  Files that have proper v1.0 blocks
in place but also have extra blocks not defined in the v1.0 spec - seems to
me - should be something other than v1.0 files.


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

Agreed.


Regarding my point about capinfos being useful for debugging, this is what
happens when it reads a file with all the blocks encrypted and everything
else well-formed (so long as the file version is set to v1.0) but no EPBs
it can read - note the file size:

File name:           network-tap.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
Packet size limit:   file hdr: (not set)
Number of packets:   0
File size:           564 kB
Data size:           0 bytes
Capture duration:    n/a
Start time:          n/a
End time:            n/a
Data byte rate:      0 bytes/s
Data bit rate:       0 bits/s
Average packet size: 0.00 bytes
Average packet rate: 0 packets/sec
SHA1:                dedc65cf087e69261430690484995f3018e6d60f
RIPEMD160:           ffe06e77376b67a16eb9476117c8a67555fff560
MD5:                 4e6fec8a0945e2d6bb9dd86491a22f1c
Strict time order:   True



> _______________________________________________
> pcap-ng-format mailing list
> pcap-ng-format at winpcap.org
> https://www.winpcap.org/mailman/listinfo/pcap-ng-format
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20150903/9d7ee702/attachment-0001.html>