My reading of your list of tradeoffs is that even for pcap-NG, LINKTYPE_TEXT is required as it has no other way to record text (no comment fields, for example, attached to packet blocks.)
Actually, yes, it does - just about every block can have options attached to it, including Enhanced Packet Blocks:
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionepb
(but not Simple Packet Blocks, but those don't even have timestamps, so they can't be used if your goal is to have a superset of pcap format's capabilities), and one of the options supported by all blocks that allow options is the Comment option:
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionopt
which allows you to attach a UTF-8 string to the block.
The handling of the presence of LINKTYPE_TEXT will be the same for any other link type that is unknown to the tools that encounter it, so there's nothing new or special about that.
Nothing special, but tcpdump's handling of link types it doesn't understand is to reject the entire file - and LINKTYPE_PPI is one of the link types it doesn't understand, and I suspect that few if any other programs that read pcap files handle more types than tcpdump. A Google Code search for DLT_PPI didn't find anything, and a search for LINKTYPE_PPI found LINKTYPE_PPI_HDR in aircrack-ng, but the code appears to assume that *every* packet in a LINKTYPE_PPI file is an 802.11 packet preceded by a PPI header, without even looking at the LINKTYPE_ value in the PPI header; there's a comment referring to Kismet, so it might be able to read and write PPI, but it might also just be using it as an 802.11 metadata header rather than as a "meta-packet" header.
For that matter, it may be worthwhile improving the failure modes of tcpdump, if only in dealing with LINKTYPE_PPI.
There's not much you can do about the failure mode for handling an unknown link-layer header type; the only way to improve tcpdump's handling of LINKTYPE_PPI would be to add support for decoding and printing it, which might be a good idea, but note that you're not going to have much success with using filters on those files without the significant - and a bit ugly - changes to the way filtering is done.
So I'll ask, does anyone think that LINKTYPE_TEXT should not be added?
I think it should only be added if the goal is to quickly get something that Wireshark can sort-of handle and nobody cares whether any other tools will be able to read the files that have comments any time soon (and if I don't have to do any of the work, as, if I'm going to work on comment support in capture files, I'd rather work on adding a new API to libpcap that can let applications get the entire contents of all block types in a pcap-NG file and modifying tcpdump to use it if available). Otherwise, I'd vote for adding support for comments to Wireshark, adding the new APIs to libpcap, and modifying tcpdump to use them if available, complete with either always printing the comments or having an option to request the comments (although *that* change means we might want to consider another change, namely converting tcpdump to use getopt_long() - 1973 called, it wants its command-line flag conventions back).-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.