37
votes

We're sniffing packets using libpcap on linux The header we get on each packet looks like:

struct pcap_pkthdr {
        struct timeval ts;      /* time stamp */
        bpf_u_int32 caplen;     /* length of portion present */
        bpf_u_int32 len;        /* length this packet (off wire) */
};

Now, It is my understanding that caplen is the length of the data we have captured while len is the length of the packet on the wire. In some cases (e.g. when setting the snaplen too low when opening the pcap device) we might capture only parts of the packet, that length will be 'caplen', while 'len' is the original length. Thus, caplen should be equal to or less than len, but never greater than len.

Is that a proper understanding ? We're seing caplen > len on some machines

3
You should post the pcap that triggers this problem on pcapr.net, it would be quite interesting. Personnaly, I've never seen that.bortzmeyer

3 Answers

25
votes

Your understanding is correct, at least based on the pcap man page.

caplen is the amount of data available to you in the capture. len was the actual length of the packet.

I'm not aware of any cases that would give you a caplen > len. I usually seem them being equal as my snaplen is sufficiently high.

6
votes

Yes your understanding is right Caplen is always less than Len . Sometimes we dont need to capture the whole packet . But why would'nt you capture the whole packet given a chance ? Because in a heavy network traffic that would'nt be a good idea . Are'nt we actually losing precious data if we dont capture the whole packet that appears on the wire ? No. Actually it depends on your purpose , if you just want to classify packets based on the protocols and the application it is destined to , u just need around 14 bytes( Ethernet ) plus 20 bytes ( Ip ) + plus another 20 ( Tcp ) thus you apparently need only 54 bytes of data to classify packets based on protocols , so a lot of load and time is saved on reducing the processing size from pcappkthdr->len to pcappkthdr->caplen :)

If the headers in the packets are corrupted ( meaning that if the headerlength values are messed up somehow ) then the captured length would be greater than the actual length of the packet .

3
votes

If caplen > len, that's a bug; what version of libpcap are you using?