pcap_next调用填充pcap_pkthdr，len等于零

pcap_next call fills in pcap_pkthdr with len equal to zero

本文关键字：pcap len 等于零 填充 next 调用 pkthdr      更新时间：2023-10-16

我使用的是作为静态库（libpcap.a）构建的1.1.1版本的libpcap。当我尝试在RHEL 6 64位上执行以下代码块时（可执行模块本身构建为32位ELF图像），我出现分段错误：

const unsigned char* packet;
pcap_pkthdr pcap_header = {0};
unsigned short ether_type = 0;
while ( ether_type != ntohs( 0x800 ) )
{
    packet = pcap_next ( m_pcap_handle, &pcap_header );
    if (packet != NULL)
    {
        memcpy ( &ether_type, &( packet[ 12 ] ), 2 );
    }
    else
    {
    /*Sleep call goes here*/
    }
}
if ( raw_buff ->data_len >= pcap_header.caplen )
{
    memcpy ( raw_buff->data, &(packet[14]), pcap_header.len -14 );
    raw_buff->data_len = pcap_header.len -14;
    raw_buff->timestamp = pcap_header.ts; 
}

经过一点调查，pcap_header.len字段在pcap_next返回时等于零。事实上，caplen字段似乎相应地反映了数据包大小。如果我试图从数据包地址转储数据包内存，那么数据似乎是有效的。由于len字段等于零，我知道它是无效的。它应该至少是caplen量级。是虫子吗？我应该采取什么步骤来解决这个问题？

GDB将pcap_header内容显示为：

（gdb）p pcap_header

$1＝｛ts＝｛tv_sec＝5242946，tv_usec＝1361456997｝，caplen＝66，len＝0｝

也许我可以申请一些变通办法？我不想升级libpcap版本。

2.6.27内核之前的内核不支持在64位内核上使用libpcap 1.0或更高版本运行32位二进制文件。

libpcap 1.0及更高版本在Linux内核上使用"内存映射"捕获机制，该机制的第一个版本没有确保内核和使用"内存映像"捕获机制的代码之间共享的数据结构在32位和64位模式下以相同的方式在内存中布局。

2.6.27内核之前的2.6内核只有该机制的第一个版本。2.6.27内核有该机制的第二个版本，确实确保数据结构在32位和64位模式下以相同的方式在内存中布局，因此32位用户模式代码在32位或64位内核上的工作方式相同。

希望我在谷歌上搜索到"https://bugzilla.redhat.com/show_bug.cgi?id=557728"缺陷描述，现在它似乎仍然相关。当我将我的应用程序链接到libpcap的共享库版本，而不是将其链接到静态库版本时，问题就消失了。然后，系统在运行时将我的程序链接到RHEL附带的libpcap。

真诚的你，亚历山大·切尔尼亚耶夫。

相关文章：