tcpdump: „pakiety przechwycone” a „pakiety odebrane przez filtr”

Mamy skrypt, który wywołuje

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

na wielu adresach IP, podczas gdy inne części skryptu inicjują pewien ruch w tle. Chcemy sprawdzić, czy pakiety do nas wracają, i ręcznie sprawdzać tylko te przypadki, gdy otrzymujemy paczki. Wyjściowy błąd tcpdump wydawał się na początku odpowiedni, ale.

Pytanie brzmi, jak sugeruje badany, jaka jest różnica między „pakietami przechwyconymi” a „pakietami odebranymi przez filtr”? Są przechwytywania, które nie nagrywały żadnych pakietów, ale generowały „Przechwycono 0 pakietów, 2 pakiety odebrane przez filtr”, co brzmi jak sprzeczność, ponieważ jeśli żadne pakiety nie zostały przechwycone, w jaki sposób 2 z nich zostały przefiltrowane? Na początku szukaliśmy „0 pakietów odebranych przez filtr”, ale nie zawsze jest to zapisywane w wyniku błędu, gdy nie otrzymano żadnych pakietów. Co więc pokazują te liczby?

Muszę wiedzieć, czego szukać, jeśli chcemy filtrować te przypadki, w których nie otrzymano pakietów odpowiedzi.

Mam nadzieję, że rzuci to nieco światła na ten problem. Z strony podręcznika :

Kiedy tcpdump zakończy przechwytywanie pakietów, zgłosi liczbę:

przechwycone pakiety (jest to liczba pakietów, które tcpdump odebrał i przetworzył);

pakiety odebrane przez filtr (znaczenie tego zależy od systemu operacyjnego, na którym działa tcpdump, i być może od sposobu skonfigurowania systemu operacyjnego - jeśli filtr został określony w wierszu polecenia, w niektórych systemach operacyjnych zlicza pakiety niezależnie od tego, czy zostały one dopasowane przez wyrażenie filtrujące i nawet jeśli były dopasowane przez wyrażenie filtrujące, niezależnie od tego, czy tcpdump je odczytał i przetworzył, w innych systemach operacyjnych zlicza tylko pakiety, które pasują do wyrażenia filtrującego, niezależnie od tego, czy tcpdump odczytał i przetwarzał je jeszcze, aw innych systemach operacyjnych zlicza tylko pakiety, które pasowały do ​​wyrażenia filtrującego i były przetwarzane przez tcpdump);

pakiety zrzucane przez jądro (jest to liczba pakietów, które zostały odrzucone z powodu braku miejsca w buforze przez mechanizm przechwytywania pakietów w systemie operacyjnym, na którym działa tcpdump, jeśli system operacyjny zgłasza te informacje aplikacjom; jeśli nie, to jest to będą zgłaszane jako 0).

Jest też pozycja listy mailingowej z 2009 roku wyjaśniająca:

Numer „pakietów odebranych przez filtr” to ps_recvnumer od połączenia do pcap_stats(); z BPF jest to bs_recvliczba z BIOCGSTATS ioctl. Liczba ta obejmuje wszystkie pakiety przekazane do BPF; te pakiety mogą nadal znajdować się w buforze, który nie został jeszcze odczytany przez libpcap (a zatem nie został przekazany do tcpdump), lub może znajdować się w buforze, który został odczytany przez libpcap, ale nie został jeszcze przekazany do tcpdump, więc może liczyć pakiety, które nie są zgłaszane jako „przechwycone”.

Może proces jest zabijany zbyt szybko? Jest też -c Nflaga informująca tcpdump o wyjściu, gdy Npakiety zostały przechwycone.

Ponieważ Twój problem wydaje się dość wyspecjalizowany, możesz również użyć libpcapbezpośrednio lub za pośrednictwem jednego z setek powiązań językowych .

Na twoje pytanie, ponieważ wszystko, co dostajesz, to przechwycone pakiety w capture.cappliku, możesz po prostu spojrzeć na przebiegi, w których nie jest pusty, i zbadać je, tj. Uhm, policzyć linie?

tcpdump -r capture.cap | wc -l

Prawdopodobnie jest lepszy sposób użycia libpcap do zwrócenia liczby wpisów w pliku przechwytywania ...