tcpdump: «захваченные пакеты» и «пакеты, полученные фильтром»

У нас есть сценарий, который вызывает

tcpdump -v src host <IP address> and port <port number> >>out.txt 2>>err.txt -w capture.cap 

на нескольких IP-сайтах, а другие части сценария инициируют некоторый трафик в фоновом режиме. Мы хотим проверить, возвращаются ли нам пакеты, и проверять вручную только те случаи, когда мы получаем пакеты. Первоначальный вывод ошибки tcpdump выглядел нормально для этого, но.

Вопрос в том, как, по мнению субъекта, какая разница между «захваченными пакетами» и «пакетами, полученными фильтром»? Есть записи, которые не записывали никаких пакетов, но выводят «0 пакетов, 2 пакета, полученные фильтром», что звучит как противоречие, так как если пакеты не были захвачены, как два из них были отфильтрованы? Сначала мы искали «0 пакетов, полученных фильтром», но это не всегда записывалось в вывод ошибки, когда пакетов не было получено. Итак, что показывают эти цифры?

Пожалуйста, сообщите, что искать, если мы хотим отфильтровать эти случаи, когда не были получены никакие ответные пакеты.

One Solution collect form web for “tcpdump: «захваченные пакеты» и «пакеты, полученные фильтром»”

Надеюсь, это проливает свет на этот вопрос. С manpage :

Когда tcpdump завершает захват пакетов, он будет сообщать о количестве:

захваченные пакеты (это количество пакетов, которые tcpdump получил и обработал);

пакеты, полученные фильтром (значение этого зависит от ОС, на которой выполняется tcpdump, и, возможно, от способа настройки ОС – если фильтр указан в командной строке, в некоторых операционных системах он учитывает пакеты независимо от того, они соответствовали выражению фильтра и, даже если они были сопоставлены выражением фильтра, независимо от того, прочитал и обработал их tcpdump, в других операционных системах он учитывает только пакеты, которые были сопоставлены выражением фильтра, независимо от того, прочитал ли tcpdump и обрабатывали их еще, а на других операционных системах он учитывает только пакеты, которые были сопоставлены выражением фильтра и обрабатывались tcpdump);

пакеты, сброшенные ядром (это количество пакетов, которые были удалены из-за нехватки пространства в буфере, механизмом захвата пакетов в ОС, на котором запущен tcpdump, если ОС сообщает эту информацию приложениям, а если нет, будет сообщено как 0).

И есть запись в списке рассылки от 2009 года, объясняющая:

Число пакетов, полученных по фильтру, – это номер ps_recv из вызова pcap_stats() ; с BPF , это номер bs_recv из BIOCGSTATS ioctl . Этот счет включает все пакеты, которые были переданы БНФ; эти пакеты все еще могут находиться в буфере, который еще не был прочитан libpcap (и, следовательно, не передан tcpdump), или может быть в буфере, который был прочитан libpcap, но еще не передан tcpdump, поэтому он может считать пакеты, которые не сообщаются как «захваченные».

Может быть, процесс убит слишком быстро? Существует также флаг -c N указывающий tcpdump на выход, когда N пакетов были захвачены.

Поскольку вы проблема, кажется довольно специализированной, вы также можете использовать libpcap напрямую или через одну из сотен языковых привязок .

На ваш вопрос, так как все, что вы получаете, это захваченные пакеты в файле capture.cap , вы можете просто посмотреть на пробежки, где он не пуст, и изучить их, т. Е. Uhm, подсчитать строки?

 tcpdump -r capture.cap | wc -l 

Вероятно, лучше использовать libpcap для возврата количества записей в файл захвата …

  • Использование как Grep, так и Cut
  • Регистратор данных на основе tcpdump
  • может только ssh однонаправленный
  • Считайте в реальном времени выходные строки из другой команды вывода
  • Получено сообщение «ОШИБКА: не удается декодировать канал связи типа 239» при включении режима сниффера
  • Файл pcap в 20 раз меньше, чем ifconfig Разница TX / RX за тот же период
  • значение вывода tcpdump для запроса / ответа на DNS
  • Файловая система пишет, казалось бы, потерянную
  • односторонняя синхронизация файлов с унисонной или лучшей альтернативой
  • Обработка временных меток вывода tcpdump в режиме реального времени
  • «Tcpdump» для захвата последних пакетов
  • Linux и Unix - лучшая ОС в мире.