On May 16, 2007, at 2:57 PM, Jesse Norell wrote:
I hope this is an appropriate question for this group. I'm with a
group (WISPA) working on developing a standard for delivery of data to
meet the CALEA law requirements.
Why is the Women's International Squash Players Association working on
that? :-)
We'd like to use pcap as the format
for likely obvious reasons, though as I'm looking into the specifics I
run into differences in formats outlined at
http://www.tcpdump.org/pcap/pcap.html
vs.
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html
the latter being an update of the former. Am I correct in assuming
that
the first describes what is actually in use today/still, and the other
was more of an update of where things would head (likely to ultimately
be a standard)?
No.
You would be correct in assuming that what is actually in use today is
http://wiki.wireshark.org/Development/LibpcapFileFormat
which is the current libpcap format, and that
http://www.tcpdump.org/pcap/pcap.html
was an earlier version of the proposed next-generation libpcap format,
and that
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html
is an update of that proposed format - that format's current home is
on winpcap.org.
Currently, I think the only places where the next-generation format
(pcap-NG) is used are in some tools from Cace Technologies:
http://www.cacetech.com/
for, I think, some aviation instrumentation purposes.
Has any further work been done on format/etc. since then (2004)?
The page at
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html
gives the latest update as September 2006. I have some further
changes (which use some currently-reserved fields) that I need to hand
to the people working on the pcap-NG spec. They're not at all major
(they use the two Reserved bytes in the Interface Description Block to
provide multiple namespaces for link-layer types (e.g., to handle the
DLT_RAWAF link-layer type family in NetBSD).
I don't know what the current plans are for pcap-NG becoming a
standard (either official or semi-official).
Perhaps we can word our standard such that it allows using the current
pcap format or any later format as agreed by both parties (law
enforcement and the entity performing the wiretap).
I would suggest that, unless you need the features of pcap-NG, you
word the standard to support the current libpcap format or any later
format as agreed by both parties. If you need a version of that
format published on the tcpdump.org site (to make it more "official",
although the core tcpdump/libpcap/WinPcap/Wireshark development groups
overlap).
If you need the pcap-NG features, note that tcpdump, Wireshark, snort,
etc. don't support it - and libpcap doesn't support it.
If/when a newer
version of pcap would come out, do you anticipate libpcap will support
backwards compatibility?
If pcap-NG becomes official, I would expect libpcap to be able to read
both the existing libpcap format and pcap-NG. Applications written to
the existing libpcap API will be able to read pcap-NG files that don't
use incompatible features (for example, they won't be able to read
files that have multiple interfaces with different link-layer types),
but they won't see any of the information in pcap-NG files for which
there's no provision in the existing API. There will be a future API
that exposes all the capabilities of pcap-NG; applications written to
that API will be able to read existing libpcap files.
Both of the above documents list major version 1, minor version 0;
what is put in pcap files today, also 1 and 0, or will there be a
way to
tell older files from newer ones?
What is put in pcap files to day is version 2.4 of the existing
libpcap format.
There is a way to tell existing libpcap files from pcap-NG files
(existing libpcap files begin with 0xa1 0xb2 0xc3 0xd4 or with 0xd4
0xc3 0xb2 0xa1, depending on the native byte order of the machine that
wrote the file; pcap-NG files begin with a Section Header Block, which
starts with a block type of 0x0d0a0a0d, a 4-byte block length, and a 4-
byte Byte-Order Magic value that's either 0x1a2b3c4d or 0x4d3c2b1a,
depending on the native byte order of the machine that wrote the file
- you need to look at that *before* you interpret the 4-byte block
length).
Both file formats include version numbers, which is how you tell older
versions of the format from newer versions.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.