tcpdump: "paquetes capturados" frente a "paquetes recibidos por filtro"

Tenemos un script que llama

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

en múltiples IP-s mientras que las otras partes del script inician algo de tráfico en segundo plano. Queremos verificar si los paquetes vuelven a nosotros y examinar manualmente solo aquellos casos cuando recibamos paquetes. La salida de error de tcpdump parecía estar bien para esto al principio, pero.

La pregunta es, como sugiere el sujeto, ¿cuál es la diferencia entre "paquetes capturados" y "paquetes recibidos por filtro"? Hay capturas, que no registraron ningún paquete, pero arrojaron "0 paquetes capturados, 2 paquetes recibidos por filtro", lo que suena como una contradicción, ya que si no hay paquetes capturados, ¿cómo se filtraron 2 de ellos? Al principio, habíamos estado buscando "0 paquetes recibidos por filtro", pero eso no siempre está escrito en la salida de error, cuando no se recibieron paquetes. Entonces, ¿qué muestran estos números?

Necesito saber qué buscar si queremos filtrar esos casos cuando no se recibieron paquetes de respuesta.

Espero que esto arroje algo de luz sobre el tema. Desde la página del manual :

Cuando tcpdump termine de capturar paquetes, informará recuentos de:

paquetes capturados (este es el número de paquetes que tcpdump ha recibido y procesado);

paquetes recibidos por filtro (el significado de esto depende del sistema operativo en el que esté ejecutando tcpdump, y posiblemente de la forma en que se configuró el sistema operativo; si se especificó un filtro en la línea de comandos, en algunos sistemas operativos cuenta los paquetes independientemente de si fueron emparejados por la expresión del filtro e, incluso si fueron emparejados por la expresión del filtro, independientemente de si tcpdump los ha leído y procesado todavía, en otros sistemas operativos solo cuenta los paquetes que coincidieron con la expresión del filtro, independientemente de si tcpdump ha leído y los procesó todavía, y en otros sistemas operativos solo cuenta los paquetes que coincidieron con la expresión del filtro y fueron procesados ​​por tcpdump);

paquetes descartados por el núcleo (este es el número de paquetes que fueron descartados, debido a la falta de espacio en el búfer, por el mecanismo de captura de paquetes en el sistema operativo en el que tcpdump se está ejecutando, si el sistema operativo informa esa información a las aplicaciones; si no, será reportado como 0).

Y hay una entrada en la lista de correo de 2009 que explica:

El número de "paquetes recibidos por filtro" es el ps_recvnúmero de una llamada a pcap_stats(); con BPF , ese es el bs_recvnúmero de BIOCGSTATS ioctl. Ese recuento incluye todos los paquetes que se entregaron a BPF; esos paquetes pueden estar todavía en un búfer que aún no ha sido leído por libpcap (y por lo tanto no entregado a tcpdump), o puede estar en un búfer que ha sido leído por libpcap pero aún no entregado a tcpdump, por lo que puede contar los paquetes que no se informan como "capturados".

Tal vez el proceso se mata demasiado rápido? También hay una -c Nbandera que le dice a tcpdump que salga cuando Nse capturaron paquetes.

Como su problema parece bastante especializado, también puede usarlo libpcapdirectamente o mediante uno de los cientos de enlaces de idiomas .

A su pregunta, dado que todo lo que obtiene son los paquetes capturados en el capture.caparchivo, simplemente puede mirar las ejecuciones donde no está vacío y examinarlas, es decir, uhm, ¿contar las líneas?

tcpdump -r capture.cap | wc -l

Probablemente haya una mejor manera de usar libpcap para devolver el número de entradas en el archivo de captura ...