Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?

From: "Gianluca Varenni" <gianluca.varenni@xxxxxxxxxxxx>
Date: Fri, 12 Jan 2007 11:30:57 -0800

----- Original Message ----- From: "Guy Harris" <guy@xxxxxxxxxxxx>
To: "Developer support list for Wireshark" <wireshark-dev@xxxxxxxxxxxxx>
Sent: Friday, January 12, 2007 10:21 AM
Subject: Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?


Benn Bollay wrote:

How difficult will the integration into the std tools (tcpdump,
Wireshark, et al) be once a consistent API is implemented?  One wonders
if it would be possible to provide a pcap interface to a pcap-ng file,
and circumvent a lot of the immediate compatibility issues.

That's certainly my intent for libpcap in the future.

I want to provide two interfaces:

1) the existing libpcap API, which will handle as much of pcap-ng as it
can (ignoring some records, discarding some data in others, failing as
soon as it sees a link-layer type other than the first one it saw);

I think the main problem here is how to deal with multiple capture interfaces within a section and multiple sections.


2) a newer API, which exposes the full capabilities of pcap-ng, and
also transparently supports reading old-style libpcap files.

I would prefer to have a separate API set (being it NTAR or anything else) to deal with capture files.

One of the things I like less about libpcap is that the API to read/write files is too much tied to the capture one without any specific reason.

Have a nice day
GV




That would give applications using libpcap to read captures (such as
tcpdump) transparent pcap-ng support (I'd convert tcpdump to use the
newer API if available, with the configure script checking for it).
Libpcap-based applications would be able to handle "typical" pcap-ng
files without change; if they changed to support the new API's, they'd
be able to handle all pcap-ng files (assuming they support all the
possible link-layer types) and still support old-style libpcap files.

Wireshark has its own code to read libpcap files; its Wiretap library's
API, etc. is a bit different, as it's oriented towards random access and
support for non-libpcap-style file formats.  The API would be changed to
handle pcap-ng's capabilities (which might also allow support to be
added for other capture file formats' capabilities).

(If the Wiretap API were ever stable enough that we'd have good reason
to think we wouldn't have to change it to support new capture file
formats or new capabilities or link-layer types in existing file
formats, we could perhaps consider merging it with libpcap - but the
different licenses, BSD vs. GPL, would be a problem with that.  Given
that Wireshark's release cycles are faster than libpcap's, we wouldn't
be ready to consider that until we have something we don't think we'd
need to change faster than libpcap.  I.e., I think we'll probably
continue to have Wiretap around for a while.)
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev