[pcap-ng-format] Some questions about SnapLen in the Interface Description Block

[Guy Harris]

The IDB section of the spec says

	SnapLen: maximum number of bytes dumped from each packet. The portion of each packet that exceeds this value will not be stored in the file. (TODO: Is there a need to signal "no limit"?)

In the tcpdump-workers message at

	http://article.gmane.org/gmane.network.tcpdump.devel/5856

somebody reported that libpcap couldn't handle pcap-ng files with a SnapLen of 0.  Some of the files came from dumpcap in Wireshark 1.7.2, which I suspect is a bug (I need to look at that some more).  Others come from "the Hone project", which I infer is

	https://github.com/HoneProject/Linux-Sensor

which apparently dates back to 2006:

	http://static.usenix.org/event/lisa06/tech/full_papers/fink/fink.pdf

and which introduces two additional block types to pcap-ng:

	https://github.com/HoneProject/Linux-Sensor/wiki/Augmented-PCAP-Next-Generation-Dump-File-Format

with block types of 257 and 258 (that's *NOT* in the "reserved for local use by the application" range; I don't know whether they requested a block type value, but I suspect not) and, apparently, defaults to a SnapLen value of 0 for "no limit" (rather than using 65535 or some other larger-than-typical-link-layer-packet value).

Given that, my inclination would be to use 0 for "no limit" (and note that any software that uses BPF filters on the packets must therefore not blindly use the SnapLen value as the return value for "matched", given that a BPF filter program that returns 0 means "drop the packet").

I would also be inclined to specify that SnapLen is an informative field, with a non-zero value indicating that the capture on that interface was done with a specified snapshot length, and that applications must be prepared to handle packets with a larger captured length than the SnapLen so that, for example, they shouldn't use the SnapLen as a fixed size buffer.  (Code that reads pcap files should be able to handle a snaplen of 0 in the header file as well, but with pcap-ng

	1) there isn't *a* snapshot length, there's one per IDB, and IDBs can appear anywhere in the capture file as long as they precede the first packet for that interface;

	2) the snapshot length is not useful for calculating a "maximum buffer size" for pcap-ng blocks, as it only applies to packet blocks and blocks can have an arbitrary amount of option data (well, as long as it doesn't exceed the 32-bit maximum for the block size)

so code that can read pcap-ng files should grow any block buffer it uses as needed.)  With 0 being a valid value meaning "no limit", the code would have to be able to grow buffers as needed anyway.