tcpdump: "захоплені пакети" проти "пакети, отримані фільтром"

У нас є сценарій, який дзвонить

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

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

Питання полягає в тому, як підказує тема, в чому різниця між "захопленими пакетами" та "пакетами, отриманими фільтром"? Є записи, які не записували жодних пакетів, але виводили "0 захоплених пакетів, 2 пакети, отримані фільтром", що звучить як суперечність, оскільки якщо жодні пакети не були захопленими, то як два з них фільтрували? Спочатку ми шукали "0 пакетів, отриманих фільтром", але це не завжди написано для виведення помилок, коли не було отримано жодних пакетів. То що ж показують ці цифри?

Мені потрібно знати, на що звернути увагу, якщо ми хочемо відфільтрувати ті випадки, коли не було отримано жодних пакетів відповідей.

Я сподіваюся, що це прояснить проблему. На сторінці сторінки :

Коли tcpdump закінчить захоплення пакетів, він повідомить про кількість:

захоплені пакети (це кількість пакетів, які tcpdump отримав та обробив);

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

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

А ще в списку розсилки з 2009 року пояснюється:

Номер "пакети, отримані фільтром" - це ps_recvномер від дзвінка до pcap_stats(); з БНФ , це bs_recvчисло з BIOCGSTATS ioctl. Ця кількість включає всі пакети, передані БНФ; ці пакети, можливо, все ще знаходяться в буфері, який ще не був прочитаний libpcap (і, отже, не переданий tcpdump), або можуть бути в буфері, який читав libpcap, але ще не передав tcpdump, тому він може рахувати пакети, які не повідомляються як "захоплені".

Може, процес вбивається занадто швидко? Також є -c Nпрапор, який повідомляє tcpdump вийти, коли Nпакети були захоплені.

Оскільки питання видається досить спеціалізованим, ви також можете користуватися libpcapбезпосередньо або через одну з сотень мовних в’язків .

На ваше запитання, оскільки ви отримуєте лише захоплені пакети у capture.capфайлі, ви можете просто подивитися на прогони, де це не порожньо, і вивчити їх, тобто, uhm, порахувати рядки?

tcpdump -r capture.cap | wc -l

Можливо, є кращий спосіб за допомогою libpcap повернути кількість записів у файл захоплення ...