用于 PCAP 实时捕捉的最佳 SNAPLEN
当使用pcap_open_live从接口嗅探时，我见过很多使用各种数字作为SNAPLEN值的示例，范围从BUFSIZ（>) 到“幻数”。
将我们正在捕获的接口的 MTU 设置为 SNAPLEN 不是更有意义吗？ 通过这种方式，我们可以在 PCAP 缓冲区中同时容纳更多数据包。假设 MRU 等于 MTU 是否安全？
否则，是否有一种非奇异的方法来设置 SNAPLEN 值？
谢谢
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
MTU 是可以交给链路层的最大有效负载大小；它不包含任何链路层标头，因此，例如，在以太网上，它是 1500，而不是 1514 或 1518，并且不足以捕获全尺寸的以太网数据包。
此外，它不包含任何元数据标头，例如 802.11 无线电信息的 radiotap 标头。
并且，如果适配器正在执行任何形式的分段/分段/重组卸载，则传递给适配器或从适配器接收的数据包可能尚未分段或分段，或者可能已重新组装，因此，可能是比 MTU 大得多。
至于在PCAP缓冲区中容纳更多数据包，这只适用于Linux中的内存映射TPACKET_V1和TPACKET_V2捕获机制，它们具有固定大小的数据包槽；其他捕获机制不会为每个数据包保留最大大小的插槽，因此较短的快照长度并不重要。对于 TPACKET_V1 和 TPACKET_V2，较小的快照长度可能会产生影响，但至少对于以太网而言，libpcap 1.2.1 会尽力为以太网选择合适的缓冲区槽大小。 （TPACKET_V3 似乎没有固定大小的每数据包插槽，在这种情况下它不会出现此问题，但它最近才出现在正式发布的内核中，并且 libpcap 中尚不支持它。）
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.)