Optimal SNAPLEN for direct capture of PCAP

Question

When using pcap_open_live to sniff the interface, I saw many examples using various numbers as the SNAPLEN value, from BUFSIZ ( <stdio.h> ) to "magic numbers".

Wouldn't it make sense to set up the SNAPLEN MTU of the interface we are grabbing from? Thus, we could place more packets at once in the PCAP buffer. Can we assume that MRU is equal to MTU?

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

thanks

Answer 1

MTU is the largest payload that can be transferred to the data link layer; it does not include headers at the link level, so for example, on Ethernet it will be 1500, not 1514 or 1518, and it will not be large enough to capture a full-sized Ethernet packet.

In addition, it does not contain metadata headers, such as a radio signal header for 802.11 radio information.

And if the adapter does any kind of fragmentation / segmentation / reassembly offload, packets sent to the adapter or received from the adapter cannot yet be fragmented or segmented or can be reassembled and, as such, can have a lot more MTUs.

Regarding the installation of more packets in the PCAP buffer, this applies only to the memory capture mechanisms TPACKET_V1 and TPACKET_V2 with memory in Linux, which have fixed packet packets; other capture mechanisms do not reserve a maximum size slot for each packet, so the shorter snapshot length does not matter. For TPACKET_V1 and TPACKET_V2, a shorter snapshot length may make a difference, although at least for Ethernet, libpcap 1.2.1 tries, as far as possible, to choose the appropriate buffer size for Ethernet. (TPACKET_V3 does not seem to have fixed sizes for each package, in which case it would not have this problem, but it only appeared in officially released kernels recently, and there is no support for it in libpcap yet.)