Comments below are in less relevant order.

May 03, 2007 - Upgraded libpcap to include most features found in libpcap-0.9.5. In particular, the changes which improve bpf in the face of vlan. Also, this version has been tested on an HP Proliant DL385 system with approximately 27T of Xserve raid as 1 file system and a 3 Gbyte ring buffer.

Apr 17, 2006 - Oops, removed truncate stuff from May 10, 2006. Found some files were not getting truncated properly. Back to the drawing board. Please try libpcap-0.9.20060417.tar.gz. Also, a new ring allocation method yields rings of 1,351,680 frames with a snapshot size of 1514. Of course you need the memory to do it as well as an amd64 kernel running 2.6.>14. Those of you with memory restraints will have to do some fiddling. I've not generated an algorithm to figure out how much you want to devote to packet capture.

May 10, 2006 - This libpcap is built to open savefiles and pcap files read/write. Upon close the files are truncated to appropriate end of file. This feature accomodates round robin copies over previous files of the same name, and is an attempt to limit the lost of packets due to excessive disk activity re-opening a pcap file in the 8 to 10 Gig range (5 minutes for me).

Aug 26, 2005 - Added some commentary to pcap.3. Try building an rpm using packaging/doit (need the usual /usr/src/redhat hierarchy).

Aug 14, 2005 - Made some changes to help build rpm, see packaging directory.

Aug 11, 2005 - Fixed Aug 10 release install process in Makefile.am to accomodate previous releases correctly.

Aug 10, 2005 - Brought up to date with tcpdump.org libpcap.

Jul 27, 2005 - Further testing confirmed that the Jul 26 release worked properly on an x86_64. You might want to try the latest tcpdump with the 20050727 libpcap release:

Jul 26, 2005 - This release works on linux 2.6.12 x86_64 as well as other releases of linux. The current tcpdump at tcpdump.org builds with this library. Please let me know if it does not work for you on a linux/64bit machine.

Special thanks to Steve Miller and Daniel Black whos comments led to the mmap based packet capture working on linux 64bit architectures and for eliminating the PROT_EXEC on mmap calls. Also a special kudo for Kyle Wheeler who pointed out a problem with passing the header structure back to the callback in pcap_ring_recv. These fixes, and a few updates to get more or less in line with tcpdump.org, should allow the mmap pcap to function on an Opteron system running linux.

Feb 6, 2005 - For the first time in my life I made a Debian package. Actually, two:

And to be honest, I used the debian packages created by: for libpcap0.8 as a template. The above packages provide my Jan 29 libpcap.

Jan 29, 2005 - Made a grody patch to pcap-ring.h so that, if the macro mb() is not defined, it will be. This is the result of some linux distributions which have taken to heart the desire to separate the kernel and user world vis-a-vis /usr/include/{linux,asm}/*. Those that have severed the informal relationship which allowed us foolish sorts to use symlinks to the relevant kernel source include hierarchies, could not compile the libpcap I provide. So, you RedHat users living in a 2.6.9-1.715_FC3smp world, or moral equivalent can now pull down version 20050129 or greater and hopefully build a libpcap replacement for the one they provided.

On the "why-oh-why" front, RedHat delivers tcpdump with a static libpcap library. So, you cannot reap the benifits (if any) of my take on "af_packet" which is the kernel module that provides the RX_RING mechanism.

One more thing. Make sure you have an ethernet card that is NAPI aware and that you configure your kernel as such. I currently use a NAPI aware e1000.

Memory needed:
You will need approximately 134217728 bytes of additional memory to hold the maximum number of packets accomodated by the current kernel af_packet ring buffer algorithm. You can always set PCAP_FRAMES to a number. The amount of memory needed will be basically that number times the page size devided by the snaplen. To understand and do an even better calculation please refer to the document mentioned below.

Jan 19, 2005 - Fixed PCAP_FRAMES=max to calculate a maximum based on linux kernel source documentation:

Try it you will like it (assuming you have enough memory on your machine). Let's say you only want to capture the IP header and a couple of port numbers:

That should give you 917,504 frames on the ring. If it fails you will have to do some finageling by adjusting the value of PCAP_FRAMES by hand. Sorry, there is only so much I'll do for free.

Oct 29, 2004 - Current release from Oct 23 was found wanting. Install failed and PCAP_STATS feature was a tad wrong. Symptom was that retrieval of first packet identified by start date in stat file was found to be at tail end of previous pcap file. I was off by one, more or less. Should be fixed in version 1.0.20041001. Install required a right paren at end of:

Oct 23, 2004 - Fix to stats where consecutive reads with out a poll count was not being set properly. If you are developing code with this libpcap version, then your build will work better when loading from /usr/lib with -lpcap. I didn't realize that the libpcap.so symlink is needed in this case.

Oct 1, 2004 - The 20040930 release re-introduces the poll counter which I dropped inadvertently a while back. Also, it suppossedly is in sync with the current libpcap and tcpdump at tcpdump.org. Debian applications such as tcpdump 3.8.3-3, tcpflow 0.21-1, and tethereal 0.10.6-2 work just fine. Configuring with "--prefix=/usr --enable-shared" creates appropriate symlinks in /usr/lib such that the above applications run with no changes. The PCAP environment variables cause expected behavior.

Begin build issues:
If your compilation fails because it cannot find 'mb' then you need to get a kernel-source that matches your running kernel (within reason) and run:

The above assumes you are on a Debian system.

Also, remember after extracting libpcap source, you should probably run:

Then check the .warrentee file.
End build issues:

Sep 17, 2004 - The 20040826 release has fixes to some crud that crept in sometime over the last 2 or three releases. Please let me know of any problems with it. It is know to run on 2.4.27 and 2.6.8 with a NAPI enabled e1000 (at least I think it is enabled %^), and with a 1514 snaplen you can set PCAP_FRAMES=65536. If anyone has the actual code/configuration modifications to build a kernel to increase the linux page size to some multiple of 4096, let me know. If you send in any problem reports, please have an example run with PCAP_VERBOSE=1 enabled. Thanks.

Jul 06, 2004 - The 20040706 release has no new linux features. Major differences have to do with BPF support for MPLS.

May 05, 2004 - The 20050505 release has a modification to pcap_open_live which will error out if the memory you request (resulting from the interpretation of PCAP_FRAMES=) cannot be obtained. This release has been tested and found to build a replacement library in /usr/lib which will support the various pcap applications such as tcpdump with out recompiling and/or loading them. This is tenuous, and assumes the that the dependencies are for some subset of /usr/lib/libpcap.so.0.7* files. It would be best to upgrade your pcap application suite to those dependent on /usr/lib/libpcap.so.0.7. Of course, you can generate a static library, compile your own application and load from the static library, by passing any version dependencies which might bite using the shared library.

As far as I know, this 20040505 release is backward compatable with all pcap based applications whether they were loaded using libpcap 0.8.3, 0.7.n, or 0.6.n. If you know that a pcap application requires libpcap.so.0.6, you might get away with doing a sym link like so:

after having installed 20040505. I don't think I'd take that route.

Apr 22, 2004 - The 20040422 release has been tested on a Debian linux-2.4.26 distribution. The 2.4.26 kernel has the Ulises Alonso patch for af_packet.c which removes the frame number limit and fixes a packet_set_ring memory leak. Consequently, you can now set PCAP_FRAMES to numbers greater than 32760 (assuming you have the memory to support it). If you have coded up scripts which set PCAP_FRAMES=max, the program will set the number of frames to 32760 for backward's compatibility. There is no limit enforced, so this could be a cause for concern. I have not tried to blow the kernel out of the water by setting the number of frames to some outrageous amount.

Apr 06, 2004 - The initial release of libpcap-1.0 has been modified on the expectation that a patch related to limits on the maximum mmap size will be soon released for linux kernel 2.4.25 and 2.6.4+. Using this version with these patches will increase performance (decrease the loss of packets at gig-e speeds).

linux-2.6.x Issue: I've found that the libpcap supported at this site did not work on 2.6 kernels. The problem has to do with when to bind the PF_PACKET socket to an interface. The original turbo pcap library created by Alexey Kuznetsov actually 'binds' in the pcap_setfilter subroutine. The pcap-linux.c code maintained at tcpdump binds within the pcap_open_live subroutine. I've been attempting to maintain the memory mapped ring buffer implimentation orginated by Alexey by combining his algorithms with the changing libpcap source found in cvs at tcpdump.org. It has gone well up to and including linux-2.4.x kernels. However, with the advent of 2.6, while Alexey's original MMAP-ed tcpdump implimentation continued to function, my libpcap revisions failed when attempting to use the ring buffer feature. After, a painful investigation, I got it to work by binding in the pcap_setfilter routine. This somehow seemed wrong. So, the call to bind is now the last system call in pcap_open_live which appears to work. To try this out get libpcap-0.8.20040115.tar.gz.

Note: libpcap-0.8.031204 was fixed in the accounting department so that calls to pcap_stat will return correct values. They were being corrupted by my careless disregard for what happens when BPF filters are applied, or not. It should be noted that ps_recv returns the sum total of both packets put on the ring and packets discarded. Also, that total can be more than those processed by the application. If a filter is applied which is designed to remove half the packets (I don't know how to do that), then ps_recv will be a sum of half the packets plus any drops. On BSD systems ps_recv would still reflect the total number of packets seen on the net, since filtering is applied after ps_recv is incremented. If you want to see my explanation of this click here.

Note: libpcap-0.8.031201 has been tested for two special cases:

and then setting PCAP_PERIOD equal to 10000 (10 seconds) and PCAP_STATS=0x1fff for both tests. A constant packet stream of icmp echo packets was in place for the tests. The resulting output to stderr (statistics) and stdout (pcap file) were consistant (they were not in previous releases). By consistant I mean that the first packet time and last packet time in a particualar pcap file matched the first and last stat record for the statistics collected while that pcap file was receiving packets. If this is all just too confusing, imagine how I feel!.

Note: libpcap-0.8.031117 attempted to remove some crufty code that had crept into the code that keeps track of time while taking packets off the ring. However, I've since found some problems with the revised code. You should rid your system of any 031117 releases.

Note: libpcap 030530 includes pcap_next_ex patched to build without complaint.

Note: libpcap 030214 will not build without pf.h (030326 is ok).

Note: libpcap 030212 will not build. The include file bpf.h was relegated to pcap-bpf.c. Instead a new include file pcap-bpf.h is used to share DLT_ values with the bpf_filter.c code, while the native BSD pcap-bpf.c file includes bpf.h supplied by the "vendor". So, pull down the 030218 version.

Note: libpcap build default behavior is prefix=/usr/local and build static library only.

What's with this libpcap-0.8 stuff?

The suffix on the libpcap tarball stands for the year, month, day that the mmap code was merged into the tcpdump.org release. In a sense I'm riding a saucer down an extremely slippery slope (think Christmas Vacation, the movie). However, it appears to work. Let me know how it goes. Versions later than 030206 have a Makefile.am and configure.ac. The bootstrap program will use these files to create the configure file. However, since this is basically a Linux thing, you might just try:

  • ./configure
    or
  • ./configure --enable_shared
I'm running with the beta/current release. The usage of the 'to_ms' argument to pcap_open_live has been changed dramatically. Also, the pcap_setnonblock and pcap_getnonblock are recommended as the way to set 'nonblocking' mode. However, a -1 value for to_ms will also do the job.
Basically, this is still the mmap'd stuff tracking the current libpcap at tcpdump.org. WITH ONE MAJOR EXCEPTION!
The 'to_ms' argument to pcap_open_live has taken on a new meaning. If you have ever used a negative or zero value for to_ms, you will have to revise your source.
My linux mmap'd pcap behaves as follows:
  1. With a positive timeout (initialized by the to_ms value on each call to pcap_read), a "read" will return if either
    1. enough polls have been called to exhaust the timeout value,
      or
    2. the timeout expires even if no packets have been received.
  2. With a zero timeout, a "pcap_read" will never return. The timeout is considered infinite. Of course callbacks will continue for each packet that arrives.
  3. With a value of -1, "pcap_read" will return if either
    1. there are no packets on the ring,
      or
    2. the packets that have been queued on the ring have all been processed. In otherwords, it is non-blocking. The recommended 'non blocking' mechanism is to use 'pcap_setnonblock' and 'pcap_getnonblock' to set/unset or retrieve the blocking/nonblocking state. In otherwords, calling pcap_setnonblock is equivalent to calling pcap_open_live with to-ms == -1.
Basically, the only system call that comes into play while in pcap_read is the poll system call. And that is only for cases 1 and 2.

What's new with beta release (August 15, 2002).

Fixed a self inflicted problem with pcap_open_live in non-root mode.
In the previous release I managed to reinstall a bug. The problem manifisted itself in non-root mode with a segfault when the user attempted to open a live interface. If you are using August 9 release you should get this one.

What's new with beta release (August 9, 2002).

Incorporated tcpdump.org current libpcap-0.8 features.
This involved mainly the addition of pcap_findalldevs. The ring code was not modified. It would be nice if you tested this and let me know how it goes. Applications that want to use pcap_findalldevs must be re-coded to call the feature. As far as I can tell, on linux it finds all the devices in /proc/net/dev and adds the "any" device, and then you can reference them by a number (1, 2, ...) with the "-i" switch.

Will the MMAP libpcap package compile on Solaris 8 or freeBSD

By golly, it will, and it will generated a shared library too. But, you would need to install flex and bison along with all the other gnu programming environment stuff like autoconf, etc. Also, solaris and BSD is not linux, so mmap stuff is not relevant.

What's new with beta release (June 18, 2002).

tcpdump Segmentation fault (core dumped)
Manifested when starting tcpdump as non root user. Setting the correct value for ebuf in call to live_open_old fixed problem.

What's new with beta release (June 17, 2002).

LOOPBACK
Fixed reporting duplicates when using MMAP and device "any".
Shuffled code
Move some binding code back to pcap_open_live from where I had moved it (pcap_setfilter).

What's new with the Flag day release (June 14, 2002).

PCAP_STATS
The problem with PCAP_STATS and TO_MS=0 has been solved. The problem manifested itself as erratic or absent statistics when in nonblocking mode.
PCAP_FRAMES=0
This turns off the memory mapped feature. Which should allow for a comparison of memory mapped operation (no system calls) verses one system call per packet operation.
-i any
Setting the device to any on a call to pcap_open_live now works in memory mapped mode. That is to say the network device can be specified as "any" and cooked packets will be put on the ring by the kernel for all interfaces seen by ifconfig. This corresponds to the latest libpcap from tcpdump.org which has code in the pcap_read_packet (called by pcap_loop, pcap_dispatch, etc.) to handle the any device. The PCAP_STATS code has been modified to add the packet stats for each device together when in this mode.
PCAP_VERBOSE=1
The expository message displayed by libpcap when PCAP_VERBOSE is set, is a tad more relevant.
Non Blocking IO supported
The current libpcap at tcpdump.org has defined two new API subroutines:
  • pcap_setnonblock (p, nonblock, errbuf)
  • pcap_getnonblock (p, errbuf)
These are now honored by the current MMAP version of libpcap. Non blocking IO is useful when you have a multitude of other devices open (pipes to other processes, such as printers, storage devices that need special attention, Normally, this is set up in a poll loop which selects all relevant devices and waits for something to do. If you did not accomodate this by using a short or non-existant wait to_ms, you could suffer from serious timing issues.
pcap_setfilter return code
It was possible to get one of three different return codes from pcap_setfilter.
  • -1 failure
  • 0 success (RING not compiled into the kernel)
  • 1 success (Using shared memory mapped ring buffer)
Since this is not in the API, and was an issue with Mike, I returned to the original -1 and zero return scheme.