PCAP结构pcap_pkthdr LEN VS caplen

我们使用嗅探的libpcap在linux上我们得到的每个数据包的报头包看起来像：PCAP结构pcap_pkthdr LEN VS caplen

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

来源

2009-09-29 nos

您应该在pcapr.net上发布触发此问题的pcap，这将非常有趣。 Personnaly，我从来没有见过。 – bortzmeyer 2009-09-29 20:42:37

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

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

我不知道任何情况下，会给你一个caplen> len。我通常觉得他们是平等的，因为我的脾气足够高。

来源

2009-09-29 16:11:30 Jason

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

如果标头在数据包被破坏（意味着如果头长度值以某种方式混乱），则捕获的长度将大于数据包的实际长度。

来源

2013-01-02 16:22:25 wanttomasterpython

如果caplen> len，那是个bug;你使用的是什么版本的libpcap？

来源

2013-01-05 22:21:28

PCAP结构pcap_pkthdr LEN VS caplen

回答

相关问题