Re: pcapng save files

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

On Jul 2, 2014, at 2:47 PM, Michael Richardson <mcr () sandelman ca> wrote:

> There has been discussion at the IETF about standardizing PCAPNG,
> and I was just wondering where we were in actually using it ourselves!
> It's better than I had feared, but worse than I'd hoped.
>
> As far as I can tell, we have support in libpcap for reading from pcapng
> save files, but we do not have in libpcap support for writing in that
> format, nor do we have a way to tell tcpdump to output to a specific
> kind of savefile. (Please correct me if I'm wrong)

Correct.

The current libpcap support uses the existing APIs, which can't expose the full capabilities of pcap-ng; it requires 
all interfaces in the pcap-ng file to have the same link-layer header type and snapshot length, and all sections of the 
pcap-ng file to have the same byte order.  (Then again, Wireshark requires all sections of the pcap-ng file to be the 
same section :-); it currently supports only one section.  This needs to be fixed as well.)

OS X Mountain Lion has changes to libpcap and tcpdump that allow tcpdump to write pcap-ng files (-P specifies "write 
pcap-ng"); sadly, those changes are under the APSL, patent clauses included, so I'm loath to incorporate them into our 
libpcap and tcpdump.

> PCAPNG is magic 0x1A2BC3D4.
> PCAP is magic   0xa1b23c4d.
> I would have liked if PCAPNG had used the same magic, and actually just
> bumped the PCAP_VERSION_MAJOR...

I.e., if the major version number of the file is 3, the rest of the file header would look more like a pcap-ng Section 
Header Block, with the magic number being the block type?

> Did anyone tell the /bin/file people about the PCAPNG magic number?

Yes:

        #
        # "pcap-ng" capture files.
        # http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html
        # Pcap-ng files can contain multiple sections. Printing the endianness,
        # snaplen, or other information from the first SHB may be misleading.
        #
        0       ubelong         0x0a0d0d0a
        >8      ubelong         0x1a2b3c4d      pcap-ng capture file
        >>12    beshort         x               - version %d
        >>14    beshort         x               \b.%d
        0       ulelong         0x0a0d0d0a
        >8      ulelong         0x1a2b3c4d      pcap-ng capture file
        >>12    leshort         x               - version %d
        >>14    leshort         x               \b.%d

> Anyway, I'm thinking that there should be another tcpdump 4.x release
> that writes to pcap format by default, but has an option to force output
> format to pcapng, and then a 5.x release that defaults to writing pcapng.

Yes; the new libpcap would have a new API that can read pcap and pcap-ng files and expose the full capabilities of 
pcap-ng, and another new API that can write pcap-ng files (and perhaps also pcap files; that would let us fix some 
infelicities in the current pcap writing API, such as not being able to get a write error indication or a close error 
indication), and tcpdump would, if those APIs are available in libpcap, use the new APIs to read files and would offer 
a -P flag to write pcap-ng files.  (The existing APIs would remain, for the benefit of programs not yet changed to use 
the new APIs.)

Tcpdump 5.x would do the same, but write pcap-ng files by default; I'm not sure whether we should then make -P specify 
"write pcap" or add a new option for that.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers