вызов pcap_next заполняет pcap_pkthdr с len равным нулю

я использую Libpcap версии 1.1.1 построен как статическая библиотека (libpcap.a). Когда я пытаюсь выполнить следующий блок кода на 64-битном RHEL 6 (сам исполняемый модуль построен как 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 версия.

1

Решение

Ядра до версии 2.6.27 не поддерживают запуск 32-битных двоичных файлов с использованием libpcap 1.0 или более поздней версии на 64-битном ядре.

В libpcap 1.0 и более поздних версиях используется механизм захвата с отображением в памяти в ядрах Linux, в которых он есть, и первая версия этого механизма не обеспечивала совместное использование структур данных между ядром и кодом с использованием механизма захвата с отображением в память были расположены в памяти одинаково в 32-битном и 64-битном режиме.

Ядра 2.6, предшествующие ядру 2.6.27, имеют только первую версию этого механизма. Ядро 2.6.27 имеет вторую версию этого механизма, которая делает убедитесь, что структуры данных расположены в памяти одинаково в 32-битном и 64-битном режиме, чтобы 32-битный код пользовательского режима работал одинаково в 32-битном и 64-битном ядрах.

1

Другие решения

Надеюсь, я погуглилhttps://bugzilla.redhat.com/show_bug.cgi?id=557728«описание дефекта, и кажется, что оно все еще актуально в наши дни. Проблема исчезла, когда я связал свое приложение с версией общей библиотеки Libpcap вместо того, чтобы связать его со статическим. Затем система связывает мое приложение с Libpcap во время выполнения, которое поставляется с RHEL.

С уважением, Александр Черняев.

0

По вопросам рекламы [email protected]