tcpdump: "pacchetti catturati" vs "pacchetti ricevuti dal filtro"


11

Abbiamo una sceneggiatura che chiama

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

su più IP-s mentre le altre parti dello script avviano un po 'di traffico in background. Vogliamo verificare se i pacchetti ci vengono restituiti ed esaminare manualmente solo quei casi quando riceviamo i pacchetti. All'inizio l'output dell'errore di tcpdump sembrava a posto per questo, ma.

La domanda è, come suggerisce il soggetto, qual è la differenza tra "pacchetti catturati" e "pacchetti ricevuti dal filtro"? Ci sono acquisizioni, che non hanno registrato alcun pacchetto, ma hanno prodotto "0 pacchetti catturati, 2 pacchetti ricevuti dal filtro" che sembra una contraddizione, dal momento che se nessun pacchetto è stato catturato, come sono stati filtrati 2? Inizialmente, stavamo cercando "0 pacchetti ricevuti dal filtro", ma ciò non è sempre scritto nell'output degli errori, quando non sono stati ricevuti pacchetti. Cosa mostrano questi numeri?

Devo sapere cosa cercare se vogliamo filtrare quei casi quando non sono stati ricevuti pacchetti di risposte.

Risposte:


12

Spero che questo faccia luce sulla questione. Dalla manpage :

Quando tcpdump termina di acquisire i pacchetti, riporterà i conteggi di:

pacchetti acquisiti (questo è il numero di pacchetti che tcpdump ha ricevuto ed elaborato);

pacchetti ricevuti dal filtro (il significato di ciò dipende dal sistema operativo su cui stai eseguendo tcpdump, e possibilmente dal modo in cui è stato configurato il sistema operativo - se un filtro è stato specificato sulla riga di comando, su alcuni sistemi operativi conta i pacchetti indipendentemente dal fatto che sono stati abbinati dall'espressione del filtro e, anche se sono stati abbinati dall'espressione del filtro, indipendentemente dal fatto che tcpdump li abbia ancora letti ed elaborati, su altri sistemi operativi conta solo i pacchetti che sono stati abbinati dall'espressione del filtro indipendentemente dal fatto che tcpdump abbia letto e li ha ancora elaborati e su altri sistemi operativi conta solo i pacchetti che sono stati abbinati dall'espressione del filtro e sono stati elaborati da tcpdump);

pacchetti rilasciati dal kernel (questo è il numero di pacchetti che sono stati eliminati, a causa della mancanza di spazio nel buffer, dal meccanismo di acquisizione dei pacchetti nel sistema operativo su cui è in esecuzione tcpdump, se il sistema operativo riporta tali informazioni alle applicazioni; in caso contrario, esso verrà segnalato come 0).

E c'è una voce della mailing list del 2009 che spiega:

Il numero "pacchetti ricevuti dal filtro" è il ps_recvnumero da una chiamata a pcap_stats(); con BPF , questo è il bs_recvnumero dal BIOCGSTATS ioctl. Questo conteggio include tutti i pacchetti che sono stati consegnati a BPF; quei pacchetti potrebbero essere ancora in un buffer che non è stato ancora letto da libpcap (e quindi non consegnato a tcpdump), oppure potrebbero essere in un buffer letto da libpcap ma non ancora consegnato a tcpdump, quindi può contare i pacchetti che non vengono segnalati come "acquisiti".

Forse il processo viene interrotto troppo in fretta? C'è anche una -c Nbandiera che dice a tcpdump di uscire quando i Npacchetti sono stati catturati.

Poiché il tuo problema sembra piuttosto specializzato, puoi anche utilizzare libpcapdirettamente o tramite una delle centinaia di associazioni linguistiche .

Alla tua domanda, dato che tutto ciò che ottieni sono i pacchetti catturati nel capture.capfile, potresti semplicemente guardare le piste in cui non è vuota ed esaminare queste, cioè uhm, contare le linee?

tcpdump -r capture.cap | wc -l

Probabilmente esiste un modo migliore di usare libpcap per restituire il numero di voci nel file di acquisizione ...


1
Inoltre, se la gestione dei pacchetti è lenta, è possibile che i pacchetti vengano rilasciati nell'hardware della scheda di rete prima che sia mai visto dal kernel.
Craig,

@Craig: la casella che esegue questo script è virtualizzata, quindi non so la velocità della scheda di rete.
Alex Biro,

@sr_: buona idea con le linee, troppo facile :) Immagino che non dobbiamo usare l'opzione -w, ma semplicemente reindirizzare l'output su un file e contare i numeri di riga. Verificherà quanto prima.
Alex Biro,

@ tuareg85: per analizzare i pacchetti acquisiti, -wè fantastico. Ad esempio puoi usare Wireshark con esso.
sr_

1
Uccidere il processo troppo presto non è probabilmente il problema, poiché aspettiamo 3 secondi dopo aver fermato il traffico, penso che dovrebbe essere sufficiente. Anche tcpdump ha il tempo di terminare anche l'output dell'errore, ei pacchetti rilasciati dal kernel sono sempre stati 0.
Alex Biro,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.