1

我正在使用作为静态库（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字段等于零，我知道它是无效的。它应该至少是卡普伦量级。它是一个错误吗？我应该采取什么步骤来解决这个问题？

GDB将pcap_header内容显示为：

(gdb) p pcap_header

$1 = {ts = {tv_sec = 5242946，tv_usec = 1361456997}，caplen = 66，len = 0}

也许我可以应用一些解决方法？我不想升级libpcap版本。

4

2 回答 2

1

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 位内核之上。

于 2013-02-21T20:40:55.443 回答
0

希望我用谷歌搜索“ https://bugzilla.redhat.com/show_bug.cgi?id=557728 ”缺陷描述，现在看来它仍然相关。当我将我的应用程序链接到libpcap的共享库版本而不是将它与静态链接时，问题就消失了。然后一个系统在运行时将我的应用程序链接到一个libpcap ，该 libpcap随 RHEL 一起提供。

此致，亚历山大·切尔尼亚耶夫。

于 2013-02-27T17:20:04.417 回答