Question

I’m writing a C application which uses the pcap library to log how much data (matching various packet filters) has passed through a network card. The values that I’m getting seem much too low to be correct, but I’m not sure what I’m doing wrong.

The test code below exhibits the same behavior (error checking omitted for clarity):

#include <stdio.h>
#include <pcap.h>

static int total=0;
void packet_handler(u_char *param, const struct pcap_pkthdr *header, const u_char *pkt_data){
    total += header->len;
    printf("%d\n", total);
}

int main(){
    char errbuf[1024];

    pcap_t *adhandle = pcap_open_live("en1", 65535, 0, 0, errbuf);
    pcap_setnonblock(adhandle, 1, errbuf);
    struct bpf_program fcode;
    pcap_compile(adhandle, &fcode, "port 80", 1, 0);
    pcap_setfilter(adhandle, &fcode);

    while(1){
        pcap_dispatch(adhandle, -1, packet_handler, NULL);
        sleep(1);
    }
    return 0;
}

I’m working on OSX, compiling with gcc, and I’ve tried downloading over wi-fi and wired ethernet. I expect the code above to print out the number of bytes that have matched the filter (in this case all HTTP traffic) but when I download a test file 4,357,017 bytes in size I get a value of only 95,133. My test file was a zip archive so I don’t think HTTP compression can account for the difference.

Update: I’ve modified the code to print out the size of each packet, as well as the running total, and also to report only the incoming packets (changed the filter to “src port 80”). This gives lots of packet lengths of ‘1514’ which I think is related to the MTU value of 1500, however the total remains far too low.

Answer 1

There is no guarantee here that your program is seeing all the packets; if it doesn’t see them, it can’t count them, in which case it wouldn’t be surprising that the sum of the captured packet lengths was less than the amount of data transferred.

First of all, you shouldn’t use non-blocking mode unless your program is doing something more than just capturing packets – polling doesn’t work better here, it can work worse. With your code, the system would run out of the BPF buffer space if more packets than fit in the buffer arrive in a second, meaning packets would be dropped and your program would never see them and would thus not count them. Prior to Lion, the default buffer size is about 32K or so, meaning there’s a very good chance that the system can run out of the BPF buffer space; Lion picks up the libpcap 1.1 change to make the default buffer size for BPF systems 512K, so that’s less likely to happen, but you still shouldn’t use non-blocking mode unless you really need it.

In addition, you shouldn’t use non-blocking mode at all on Snow Leopard, as there’s a bug in the BPF kernel code in Snow Leopard (the FreeBSD version of the bug is PR 143855); it’s not present in Leopard or before (it was introduced in a fix to a bug fixed in Snow Leopard), and it’s fixed in Lion.

So the first thing I’d do would be to get rid of the pcap_setnonblock(adhandle, 1, errbuf); call and the sleep(1); call, so that your program processes packets as fast as it can.

In addition, if it doesn’t have to run on Leopard (which had an older version of libpcap that didn’t support pcap_create() or pcap_activate()), I’d raise the buffer size to 512K by doing (error checking removed for clarity):

adhandle = pcap_create("en1", errbuf);
pcap_set_buffer_size(adhandle, 524288);
pcap_activate(adhandle);

Finally, I’d have your program somehow provide a way to be told when to stop capturing and, when it stops, have it call pcap_stats() and report the number of dropped packets, so that you can determine whether it dropped any packets.