2

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.

codebox
  • 19,927
  • 9
  • 63
  • 81
  • If you are downloading something through HTTP be sure that compressing is not used by HTTP client. – Ation Feb 05 '12 at 11:46
  • 1
    `int main(char** arcv, int argc){` Houston, we've got a problem! – wildplasser Feb 05 '12 at 11:53
  • I see two general options. Either you're getting the wrong packets, or the wrong sizes. To check the packets, you can print the source/destination ports - do you get 80 as bot source and destination port? To check the sizes, change the program to print each size - you should see lots of returning packets (source port 80) with size ~1500. – ugoren Feb 05 '12 at 12:10
  • @ugoren thanks, I'm pretty sure I'm getting the correct packets - lots of output when I send the request and nothing before or after. Why do you expect the size to be around 1500? My packet sizes are mostly much smaller (eg lots around 50-60 bytes) – codebox Feb 05 '12 at 12:17
  • Perhaps you're only getting packets from the client to the server? These are mostly ACKs, so they'll have size 50-60. The packets from the server would be as large as possible, which normally means 1500 bytes (the MTU of Ethernet interfaces), sometimes more or less (but not less than several hundreds of bytes). – ugoren Feb 05 '12 at 12:56

1 Answers1

2

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.

  • Thanks for a great answer, as you said - when I remove the call to pcap_setnonblock I get the totals that I expected, many thanks. Unfortunately my app sets up multiple filters and must write each of the totals into a database at regular intervals so if I need to use blocking calls then I suspect I will have to launch each filter in a separate thread which will add some complexity. – codebox Feb 09 '12 at 18:18
  • If you *don't* have to run on Snow Leopard, you could do it with `select()` on the results of `pcap_get_selectable_fd()` on the `pcap_t`s you're using (I'm assuming you're using multiple `pcap_t`s). However, if your machine has more than one processor core, using threads would be better, as the program could make use of more than one core. –  Feb 09 '12 at 21:03