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

Guy Harris guy at alum.mit.edu
Tue Jul 24 20:02:26 PDT 2012


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.

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

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

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


More information about the pcap-ng-format mailing list