ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

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

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 12 Jan 2007 10:21:04 -0800
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);

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

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.)