У меня есть пара файлов pcap, где длина захвата, сообщаемая Wireshark, больше, чем фактическая длина захвата. Разница составляет 10 байтов, и я не понимаю, почему он сообщает это большее число.

file сообщает то же значение, что и Wireshark в диалоге Статистика-> Сводка .

$> file out_20140207162250.pcap
out_20140207162250.pcap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 100)

Я могу использовать tshark, чтобы дать мне длину перехвата для пакетов, у которых длина перехвата короче, чем длина пакета, чтобы увидеть фактический размер.

$> tshark -r "out_20140207162250.pcap" -R "frame.cap_len < frame.len" -Tfields -eframe.cap_len | sort | uniq
tshark: The file "out_20140207162250.pcap" appears to have been cut short in the middle of a packet.
90

Глядя на файл с помощью простой C-программы, я вижу, что snaplen в pcap_file_header действительно установлен на 100.

#include <pcap.h>

int main(int argc, char **argv) {

  FILE *pcapInputFile_p;
  pcap_file_header fileHeader;

  pcapInputFile_p = fopen(argv[1], "r");
  fread( &fileHeader,sizeof(pcap_file_header), 1, pcapInputFile_p );
  printf("%d\n",fileHeader.snaplen);  
  fclose(pcapInputFile_p);

}

На самом деле я не знаю, как и каким инструментом этот конкретный файл был захвачен, но я пытаюсь это выяснить :).

Пытаясь повторить это с Wireshark 1.11.0 на моем компьютере с Windows, я установил "Ограничить размер пакета" на 96. Wireshark сообщает о каждом срезе пакета на 96, но в Статистика-> Сводка это 100, т.е. на 4 байта больше, чем я настроил. Хорошо, теперь я установил его на 106. Я получаю 106 как за пакет, так и в диалоговом окне Сводка !

Так что теперь я заинтригован ... и сегодня пятница, и я пытаюсь убить время. Я написал скрипт для захвата (с помощью dumpcap 1.8.2) одного пакета размером более 1500 и вывода его в файл. За время работы скрипта я скачал огромный файл, чтобы получить несколько больших пакетов. Система была Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux . Ниже приведен график зависимости настроенных и фактических значений длительности от 50 до 150 (шаблон повторяется как минимум до 1500). Затененные линии просто показывают, что настройка 96 дает нам 96 в этой системе. Самая большая разница составляет 2 байта, всегда меньше, чем я настроил!

Изображение сконфигурированной и фактической длины захвата (нужно повторять сообщение, не известно, как долго оно хранится)

Итак, чтобы подвести итог, почему существует разница в x байтов между сообщенной длиной захвата и фактической длиной захвата? Почему иногда? Почему разные для разных систем / инструментов? Если так, то почему? Это ошибка или я запутался?

Спасибо!

1 ответ1

0

Отвечая на мой собственный вопрос здесь, так как то, что я узнал с тех пор, как задал вопрос, "решает" его для меня. По крайней мере, мне понадобилось бы намного больше времени, чтобы понять это без помощи @GuyHarris, который любезно оставил комментарий выше, так что спасибо!

Я потратил некоторое время на компиляцию нескольких разных версий libpcap вместе с последней версией tcpdump. Результаты можно разделить на три категории (плохие, полусредние и отличные), где последняя версия libpcap прошла нормально. Сегодня, когда я повторил тест на Windows с dumpcap и Wireshark, я не мог повторить это! Я не сумасшедший, я клянусь!

Резюме - это полностью зависит от версии libpcap. Я не обнаружил, что система или любое другое программное обеспечение влияло на это. Итак, люди, обновите ваш libpcap, чтобы избавить вас от разочарований! :)

Смотрите рисунок здесь - Конфигурированная и фактическая длина привязки

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .