libpcap: the portable packet capture API behind tcpdump

What libpcap is for, and who ends up using it

The README states the problem plainly: almost every system vendor provides a different interface for packet capture. libpcap exists so an application does not have to carry several system-dependent packet capture modules. It is described there as a system-independent interface for user-level packet capture, a portable framework for low-level network monitoring, with applications in network statistics collection, security monitoring and network debugging.

The audience is therefore narrow and specific. You are writing software that needs to see packets, and you want that software to compile and run on more than one kernel. If you are writing a single-platform tool and you are happy to call that platform's capture interface directly, libpcap is a layer you may not need. If you are writing a portable analyzer, an IDS sensor, a traffic accounting daemon, or anything that has to open a capture handle, apply a filter and read frames, it is the conventional choice. tcpdump itself is built on it, which is why the repository and the project site share the tcpdump.org domain.

The library is old enough that its provenance is in the README: it came from Lawrence Berkeley National Laboratory, Network Research Group. The current maintainer is The Tcpdump Group, and security reports go to [email protected] rather than a public issue tracker.

The mechanism: capture handles, BPF programs, and where filtering happens

The filtering model comes from the BSD packet filter architecture, described in a 1993 Winter Usenix paper that the README links to. A filter is compiled into a BPF program. The interesting design question is where that program runs.

According to the README, libpcap uses in-kernel filtering only for the use cases that support BPF programs: the BPF packet capture interface, the Linux packet socket, and the GNU/Hurd interface. In all other cases libpcap reads every packet into user space and evaluates the filter there. The README is direct about the consequence, noting that this incurs added overhead, especially for selective filters. It also states the ideal that is not implemented: translating BPF filters into a program compatible with the underlying kernel subsystem.

That single paragraph is the most important thing to understand about libpcap's performance profile. A filter that rejects 99 percent of traffic is cheap on a kernel that runs BPF and expensive on one that does not, because on the latter every packet crosses into user space before being discarded. The README notes that BPF is standard in NetBSD, FreeBSD, OpenBSD, DragonFly BSD, macOS, QNX and Solaris 11, and that an older, modified and undocumented version is standard in AIX. Linux has several BPF-based systems, but the README states that libpcap does not support any of the eBPF mechanisms as yet, although it does support many memory-mapped receive mechanisms, with details in doc/README.linux.

On the build side, the repository carries configure.ac and CMakeLists.txt at the top level, so both autotools and CMake are supported. The shared library soname is set to libpcap.so.1, and the README is emphatic that this is what it should be, not libpcap.so.1.x or libpcap.so.1.x.y. The stated reason is that binary compatibility between releases has been maintained for a long time, so a binary linked against libpcap should not be tied to a particular release.

Building libpcap from source

The README points at INSTALL.md for build instructions and at the doc/ directory for README files about specific operating systems and options. Anonymous Git access is given as https://github.com/the-tcpdump-group/libpcap.git. Distribution packages are not described in the README, so if you install from a package manager, check your distribution's own documentation for the names it uses.

A source checkout is built with the autotools path. The repository ships autogen.sh and configure.ac, and the sequence is to generate the configure script, run it, then make:

./autogen.sh
./configure
make

After configure finishes it reports which capture mechanisms it found on your system. If a mechanism you expect is missing, the per-OS file in doc/ is where the README says to look, because for some platforms those files discuss how to enable support for the OS capture interface if it is not built in by default.

There is also a CMakeLists.txt at the top level and a cmake/ directory, so CMake is the alternative build path if your project already uses it. The repository additionally ships libpcap.pc.in, a pkg-config template, which is how a build system would discover the installed library.

Once the library is built and installed, the headers under the pcap directory are what your program includes, and the filter syntax you pass to the library is the same syntax tcpdump uses, which is what the related searches call libpcap filter syntax. The README does not include a worked capture example, so the entry points to look for in the headers are the ones that open a handle, compile a filter, attach it and read packets. If you only need to read an existing capture file rather than capture live traffic, the same library covers that case, which is the answer to the common question about reading a .PCAP file.

Where libpcap is the wrong tool

The clearest limitation is stated by the project itself: no eBPF support. If your design depends on eBPF programs, maps or the modern Linux tracing and filtering facilities, libpcap is not the layer that gives you them. It supports memory-mapped receive mechanisms on Linux, which is a different thing.

The second is the user-space filtering fallback. On platforms where libpcap cannot push the BPF program into the kernel, every packet is read into user space before the filter runs. For a capture that accepts most traffic this is close to free. For a narrow selective filter on a busy link it is the opposite, and the README says so. If your workload is high-rate capture with a selective filter on a platform outside the BPF set, measure before you commit, because the architecture itself predicts the cost.

The third is scope. libpcap is a capture and filtering library. It is not a protocol dissector, not a flow analyzer, not a storage format converter. The repository does include pcapng-related files and a cbpf-savefile.manfile.in, so savefile handling is part of the codebase, but the README does not present libpcap as a general packet analysis toolkit. Expect to write the analysis yourself.

One more practical point: the README's note to distributions is a warning about packaging. If you build a shared library and name it something other than libpcap.so.1, you are deviating from what the project says the soname should be.

How libpcap differs from Wireshark and from raw sockets

Wireshark is the comparison people search for, and the relationship is one of dependency rather than rivalry. Wireshark is an application with a graphical interface and a large dissector set; libpcap is a library that provides capture and filtering. The practical difference is that Wireshark answers the question of what is in this traffic, with decoding for hundreds of protocols, while libpcap answers the question of how do I get these packets into my program in a portable way. If you are investigating a problem interactively, Wireshark is the tool. If you are building something that must run unattended and make its own decisions about packets, libpcap is the layer underneath.

The second alternative is using the platform interface directly, or a language binding. On Linux that means a raw or packet socket plus your own filtering; on BSD it means the BPF device. Going direct removes a dependency and can let you use facilities libpcap does not expose, eBPF being the obvious one. It also means your code is now platform-specific, which is exactly the problem libpcap was created to solve. The related searches show libpcap python as a common concern; bindings exist, but the README does not document any of them, so treat binding documentation as coming from the binding project, not from libpcap.

The third alternative is a capture file library. If your program never opens a live interface and only reads stored captures, you are paying for a live capture framework you do not use. The trade-off is real but modest, since libpcap handles savefiles too.

Maintenance, upgrades and licence

The repository is not archived, and the last push was on 2026-09-23, so the codebase is being touched. The README does not document a release cadence, and no recent releases were retrieved, so there is no version timeline to reason about from this material. What the README does establish is a compatibility policy: binary compatibility between releases has been maintained for quite a while, and that is the stated justification for the fixed libpcap.so.1 soname. For an operator, that policy is the upgrade story. Rebuilding against a newer libpcap should not break a binary that was linked against the shared library, which lowers the cost of picking up fixes.

Upgrade cost is mostly about your own build, not the library's ABI. The build system supports both autotools (configure.ac, autogen.sh, Makefile.in) and CMake (CMakeLists.txt, cmake/), so whichever path your project already uses is available. The per-OS notes in doc/ are the files to reread when you move to a new platform, since the README says those files cover enabling the OS capture interface where it is not on by default.

The licence field for the repository is NOASSERTION, which means no standard licence identifier was detected. There is a LICENSE file at the top level. Read it directly rather than assuming a well-known licence, and if the terms matter to your distribution or product, have someone qualified review it. Nothing here is legal advice.

Editorial conclusion

Adopt libpcap if you are writing a C or C++ tool that must capture or read packets on more than one operating system, and you want one API instead of per-OS code. Do not adopt it if you need eBPF features, if you are on a platform where libpcap does not push the filter into the kernel and you care about selective-filter overhead, or if you only need to parse existing capture files. Before committing, verify three things: what the README.{system} file in doc/ says about enabling the capture interface on your platform, whether your filters will run in-kernel or in user space there, and that your shared library uses the soname libpcap.so.1 rather than a versioned name.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. the-tcpdump-group/libpcap on GitHub