pcap struct pcap_pkthdr len vs caplen

Posted 2023-03-16

【中文标题】pcap struct pcap_pkthdr len vs caplen

【英文标题】：

【发布时间】：2010-12-02 06:37:54

【问题描述】：

我们在 Linux 上使用 libpcap 嗅探数据包 我们在每个数据包上获得的标头如下所示：

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) */
;

现在，据我了解，caplen 是我们捕获的数据的长度，而 len 是网络上数据包的长度。在某些情况下（例如，当打开 pcap 设备时将 snaplen 设置得太低）我们可能只捕获数据包的一部分，该长度将是“caplen”，而“len”是原始长度。因此，caplen 应该等于或小于 len，但决不能大于 len。

这是正确的理解吗？我们在一些机器上看到 caplen > len

【问题讨论】：

您应该在 pcapr.net 上发布触发此问题的 pcap，这会很有趣。就个人而言，我从未见过。

【参考方案1】：

您的理解是正确的，至少基于 pcap 手册页。

caplen 是捕获中可供您使用的数据量。 len 是数据包的实际长度。

我不知道有什么案例可以给你一个 caplen > len。我通常看起来他们是平等的，因为我的 snaplen 足够高。

【参考方案2】：

是的，您的理解是正确的 Caplen 总是小于 Len 。有时我们不需要捕获整个数据包。但是，如果有机会，您为什么不捕获整个数据包呢？因为在繁重的网络流量中，这不是一个好主意。如果我们不捕获出现在网络上的整个数据包，我们真的不会丢失宝贵的数据吗？不。实际上这取决于你的目的，如果你只是想根据协议和应用程序对数据包进行分类，你只需要大约 14 个字节（以太网）加上 20 个字节（IP）+ 再加上另外 20 个（Tcp）因此您显然只需要 54 字节的数据来根据协议对数据包进行分类，因此将处理大小从 pcappkthdr->len 减少到 pcappkthdr->caplen 可以节省大量负载和时间 :)

如果数据包中的标头已损坏（这意味着如果标头长度值以某种方式弄乱了），则捕获的长度将大于数据包的实际长度。

【参考方案3】：

如果 caplen > len，这是一个错误；你用的是什么版本的 libpcap？

【讨论】：

我在 Ubuntu 20.04 上遇到了 libpcap0.8 + usbmon 的同样问题

这可能是 libpcap 错误 808 (github.com/the-tcpdump-group/libpcap/issues/808)，现已修复。