Optimal SNAPLEN for PCAP live capture

Question

When using pcap_open_live to sniff from an interface, I have seen a lot of examples using various numbers as SNAPLEN value, ranging from BUFSIZ (<stdio.h>) to "magic numbers".

Wouldn't it make more sense to set as SNAPLEN the MTU of the interface we are capturing from ? In this manner, we could fit more packets at once in PCAP buffer. Is it safe to assume that the MRU is equal to the MTU ?

Otherwise, is there a non-exotic way to set the SNAPLEN value ?

Thanks

Laroy

Answer 1

The MTU is the largest payload size that could be handed to the link layer; it does not include any link-layer headers, so, for example, on Ethernet it would be 1500, not 1514 or 1518, and wouldn't be large enough to capture a full-sized Ethernet packet.

In addition, it doesn't include any metadata headers such as the radiotap header for 802.11 radio information.

And if the adapter is doing any form of fragmentation/segmentation/reassembly offloading, the packets handed to the adapter or received from the adapter might not yet be fragmented or segmented, or might have been reassembled, and, as such, might be much larger than the MTU.

As for fitting more packets in the PCAP buffer, that only applies to the memory-mapped TPACKET_V1 and TPACKET_V2 capture mechanisms in Linux, which have fixed-size packet slots; other capture mechanisms do not reserve a maximum-sized slot for every packet, so a shorter snapshot length won't matter. For TPACKET_V1 and TPACKET_V2, a smaller snapshot length could make a difference, although, at least for Ethernet, libpcap 1.2.1 attempts, as best it can, to choose an appropriate buffer slot size for Ethernet. (TPACKET_V3 doesn't appear to have the fixed-size per-packet slots, in which case it wouldn't have this problem, but it only appeared in officially-released kernels recently, and no support for it exists yet in libpcap.)

Shafting

alright, so I have to "guess" a probable maximum size for the traffic I am going to monitor. – Laroy

If you're using Linux with a modern version of libpcap, and either the version isn't 1.2.1 or later or you're not capturing on Ethernet (or are capturing on Ethernet with fragmentation/segmentation/reassembly offloading), and you don't want to allocate a huge shared-memory buffer (using pcap_create()/pcap_set_buffer_size()/pcap_activate()), and want to avoid packet drops, you'll have to guess a probable maximum size for packets delivered to libpcap. – Shafting

Ok, my problem is twofold since I do not analyze each packet before getting the new one, hence I have to buffer also on user application level. That's why I am trying to trim on memory usage. – Laroy

Then you either need to have a buffering scheme in your code that doesn't allocate maximum-packet-size buffers for all packets or you have to choose a "minimum sufficient" maximum packet size; the latter is tricky (which is why libpcap only attempts it for TPACKET_V[12] in some cases). – Shafting