Re: pcap format / standard(s)

[Guy Harris <guy () alum mit edu>]

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.