On Jul 2, 2014, at 2:47 PM, Michael Richardson 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
>>12beshort x - version %d
>>14beshort x \b.%d
0 ulelong 0x0a0d0d0a
>8 ulelong 0x1a2b3c4d pcap-ng capture file
>>12leshort x - version %d
>>14leshort 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
