On Apr 5, 2011, at 11:41 AM, Darren Reed wrote:
> 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.
