tcpdump: “пакеты, полученные” по сравнению с “пакетами, полученными фильтром”

Пока у Вас есть набор "DontZap" к "прочь" в Вашем xorg.conf, можно использовать клавишу Backspace высокого звука управления для уничтожения рабочего X-сервера. Я использовал это в ситуациях, когда X сред так испорчены, я не могу выполнить команду. Если все значительно втиснуто, Вы могли бы извлечь выгоду из использования Волшебных ключей Sysrq 'k' для уничтожения всех процессов в текущем VT, и если это действительно втиснуто, можно перезагрузить систему немного более чисто, чем твердое выключение питания. К сожалению, при тестировании составления композита WMs я делал это чаще, чем я хотел бы.

11
09.03.2019, 11:05
1 ответ

Я надеюсь, что это проливает некоторый свет на проблему. Из страницы справочника:

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

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

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

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

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

"Пакеты, полученные фильтром" число, ps_recv число от вызова до pcap_stats(); с BPF это bs_recv число от BIOCGSTATS ioctl. То количество включает все пакеты, которые были вручены BPF; те пакеты могли бы все еще быть в буфере, который еще не был считан libpcap (и таким образом не вручен tcpdump), или мог бы быть в буфере, это было считано libpcap, но еще не вручено tcpdump, таким образом, он может считать пакеты, о которых не сообщают, как "получено".

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

Так как Вы - проблема, кажется довольно специализированным, Вы могли также использовать libpcap непосредственно или через одну из сотен привязок к языку.

К Вашему вопросу, так как все, что Вы получаете, является полученными пакетами в capture.cap файл, Вы могли просто посмотреть на выполнения, где это не пусто, и исследуйте их, т.е. uhm, считайте строки?

tcpdump -r capture.cap | wc -l

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

12
27.01.2020, 19:58
  • 1
    Кроме того, если пакетная обработка является медленной, возможно, что пакеты будут отброшены в аппаратных средствах NIC, прежде чем это будет когда-либо замечаться ядром. –  Craig 18.01.2012, 17:50
  • 2
    @Craig: поле, запускающее этот скрипт, виртуализируется, таким образом, я don'k знаю о скорости NIC. –  Alex Biro 18.01.2012, 18:02
  • 3
    @sr_: хорошая идея со строками, слишком легкими :) Я предполагаю, чем мы не должны использовать переключатель-w, но просто перенаправить вывод в файл и считать номера строки. Проверит тот ASAP. –  Alex Biro 18.01.2012, 18:05
  • 4
    @tuareg85: проанализировать захваченные пакеты, -w является большим. Вы можете, например, использовать Wireshark с ним. –  sr_ 18.01.2012, 18:07
  • 5
    Уничтожение процесса слишком скоро является, вероятно, не проблемой, так как мы ожидаем 3 с после остановки движения, я думаю, что это должно быть достаточно. Также tcpdump имеет время для окончания вывода ошибок также, и пакеты, отброшенные ядром, всегда были 0. –  Alex Biro 18.01.2012, 18:09

Теги

Похожие вопросы