[pcap-ng-format] Plans to finalize pcap-ng 1.1 spec during July

[Jasper Bongertz]

Hi,

>> 1. Specify that the block total length must be a multiple of four.
>> This allows simple minded parses to skip blocks they don't understand
>> without having to do any work. This aspect is ambiguous, I believe, in
>> the draft spec. It states that the contents of the block must be
>> aligned to 32 bits but the wording for the block total length does not
>> stipulate that, and there are example captures where the length is
>> two-byte aligned.

> ...which means that any code that reads pcap-ng files needs to either

>         1) handle a block total length that's not a multiple of 4;

I think this should probably be the way to go. I don't see any big problem with it, and new files should have a multiple of 4.

>         2) reject 1.0 files out of hand without going past the SHB;

Not really a good idea I guess :-)

>         3) fail as soon as they see a block with a length that's not a multiple of 4.

Less harsh but still a little to extreme I think.

> If we're going to use the 1.1 spec to deal with ambiguities and other errors, I'd also like to see us:

>         specify whether UTF-8 strings in pcap-ng files must be null-terminated or if it's sufficient for them to be counted (they all have lengths, so null-termination is redundant, and any program that reads pcap-ng files has to *somehow* handle non-null-terminated strings, either by rejecting them or by adding a null if the program is using string processing operators that require null terminators, so my inclination is *not* to require null termination);

Correct. As far as I have seen it there is only one instance where strings are required to be null-terminated, and that is for DNS record options in a NRB.


>         explicitly state that the "record length" in the Name Resolution Block is the length of the record *value*, not the record as a whole (including the record type and length);

Agreed.

>         note that a Simple Packet Block can have options (section 2.5 says "*All* the block bodies have the possibility to embed optional fields.", emphasis mine) and therefore that

>                 The amount of packet data is the minimum value among the SnapLen (present in the Interface Description Block) and the Packet Len (present in this header).  The length of the Packet Data field is the amount of packet data, rounded up to a multiple of 4 bytes.

Agreed.

>         note that software that reads pcap-ng files must not assume that no packet will have more packet data than the SnapLen for the interface on which they arrived (i.e., do *NOT* allocate a buffer with the SnapLen as its size and blithely copy data from a packet block ito that buffer);

Agreed.

> In addition, we should get rid of Appendices C and D and, instead, point to

>         http://www.tcpdump.org/linktypes.html

> as the official registry of link-layer header types.

Good idea.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3747 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20120704/6a93ebbb/attachment.bin>