[pcap-ng-format] TODO in pcap-ng specifications

[Richard Sharpe]

On Tue, Jul 24, 2012 at 8:02 PM, Guy Harris <guy at alum.mit.edu> wrote:
>
> On Jul 24, 2012, at 6:50 PM, Richard Sharpe wrote:
>
>> 2.6 Data Format
>>
>> WRT the layout of 64-bit, 128-bit etc, I agree, however, I think there
>> is a problem in the SHB in that the Block Total Length is not
>> specified unambiguously, unless I have missed something. Since it is
>> key to parsing the whole file, I think we should specify that these
>> are in LE format. All other lengths must be in the format stipulated
>> by the Byte-Order Magic, but in order to quickly make sense of a
>> pcap-ng file, the endianness of the Block Total Length must be
>> specified, unless we want people to use heuristics to figure out what
>> the byte order of that field should be, or to read in the first twelve
>> bytes, look at bytes 8 through 11 and figure out byte order from them,
>> and then interpret the field correctly.
>
> I think the latter of those is what a program should do.  If, once you've figured out the
> byte order, you find that the Block Total Length is < 16, you say "this is not a valid
> pcap-ng file" - either it's a bogus pcap-ng file or it's a non-pcap-ng file that happens
> to being with \r\n\n\r and has 1A 2B 3C 4D or 4D 3C 2B 1A starting at byte 8.

Agree ...

>> 3.2. Interface Description Block.
>>
>> SnapLen: Doesn't a value of 0 signal no limit? A capture where each
>> record contains 0 bytes is not very useful ...
>
> Well, the spec doesn't explicitly indicate that, but 0 is the obvious choice here.

Right, so we should specify that 0 means not limited.

>> Time Zone: We should check if there are standards around the
>> specification of time zones. The problem is that politicians keep
>> changing when DST starts and stops, so we need a correct mechanism.
>
> Well, there's
>
>         http://www.iana.org/time-zones/
>
> which, as long as you have up-to-date time zone data files, copes with governments
> deciding to give Clorox the opportunity to sell more charcoal briquets, or whatever.

What I was originally worried about was a capture that spanned a
period where the end and start changed, but that is probably a silly
thing to worry about at the moment.

>> Appendix D. Link Layer Headers.
>>
>> I think we can fill this in easily ... perhaps.
>
> Remove appendices C and D, and replace
>
>         * LinkType: a value that defines the link layer type of this interface. The list of Standardized Link Layer Type codes is available in Appendix C.
>
> in 3.2 "Interface Description Block (mandatory)" with
>
>         * LinkType: a value that defines the link-layer header type of this interface.  See http://www.tcpdump.org/linktypes.html for the valid link-layer header types and descriptions of the packet contents for packets with those link-layer header types.

Yes, we should refer to existing standards where possible.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)