9

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

ziu
  • 2,634
  • 2
  • 24
  • 39

1 Answers1

8

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.)

  • alright, so I have to "guess" a probable maximum size for the traffic I am going to monitor. – ziu Feb 19 '12 at 20:04
  • 2
    *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. –  Feb 20 '12 at 00:11
  • 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. – ziu Feb 20 '12 at 09:37
  • 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). –  Feb 20 '12 at 20:54