pcap struct pcap_pkthdr len 与 caplen

发布于 2024-08-06 00:50:21 字数 489 浏览 4 评论 0原文

我们在 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。

这是正确的理解吗？我们正在看到卡普伦>某些机器上的 len

原文

We're sniffing packets using libpcap on linux
The header we get on each packet looks like:

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

Now, It is my understanding that caplen is the length of the data we have captured while
len is the length of the packet on the wire. In some cases (e.g. when setting the snaplen too low when opening the pcap device) we might capture only parts of the packet, that length will be 'caplen', while 'len' is the original length. Thus, caplen should be equal to or less than len, but never greater than len.

Is that a proper understanding ? We're seing caplen > len on some machines

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

皓月长歌 2024-08-13 00:50:22

是的，您的理解是正确的 caplen 始终小于 Len 。有时我们不需要捕获整个数据包。

但是如果有机会的话，为什么不捕获整个数据包呢？
因为在网络流量大的情况下，这不是一个好主意。

如果我们不捕获线路上出现的整个数据包，我们实际上不会丢失宝贵的数据吗？
不。实际上这取决于您的目的，如果您只想根据协议和应用程序对数据包进行分类，您只需要大约 14 字节（以太网）加上 20 字节（Ip）+ 再加上另外 20 字节（Tcp）因此，您显然只需要 54 字节的数据来根据协议对数据包进行分类，因此将处理大小从 pcappkthdr->len 减少到 pcappkthdr-> 可以节省大量负载和时间;caplen :)

关于 snaplen 有时大于 len 的问题：
如果数据包中的标头被损坏（意味着如果标头长度值以某种方式混乱），则捕获的长度将大于数据包的实际长度。