tcpdump: «paquets capturés» vs «paquets reçus par filtre»

Nous avons un script qui appelle

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

sur plusieurs IP-s tandis que les autres parties du script initient du trafic en arrière-plan. Nous voulons vérifier si les paquets nous reviennent et examiner manuellement uniquement les cas où nous recevons des colis. La sortie d'erreur de tcpdump semblait correcte pour cela au début, mais.

La question est, comme le suggère le sujet, quelle est la différence entre "paquets capturés" et "paquets reçus par filtre"? Il y a des captures, qui n'ont enregistré aucun paquet, mais qui produisent "0 paquets capturés, 2 paquets reçus par filtre", ce qui semble être une contradiction, car si aucun paquet n'a été capturé, comment 2 d'entre eux ont-ils été filtrés? Au début, nous recherchions "0 paquets reçus par filtre", mais cela n'est pas toujours écrit sur la sortie d'erreur, quand aucun paquet n'a été reçu. Alors, que montrent ces chiffres?

J'ai besoin de savoir quoi rechercher si nous voulons filtrer ces cas où aucun paquet de réponse n'a été reçu.

J'espère que cela jette un peu de lumière sur la question. Depuis la page de manuel :

Lorsque tcpdump a fini de capturer les paquets, il signalera le nombre de:

paquets capturés (c'est le nombre de paquets que tcpdump a reçus et traités);

paquets reçus par filtre (la signification de cela dépend du système d'exploitation sur lequel vous exécutez tcpdump, et peut-être de la façon dont le système d'exploitation a été configuré - si un filtre a été spécifié sur la ligne de commande, sur certains systèmes d'exploitation, il compte les paquets, qu'il soit ils ont été mis en correspondance par l'expression de filtre et, même s'ils ont été mis en correspondance par l'expression de filtre, indépendamment du fait que tcpdump les ait lus et les ait encore traités, sur d'autres systèmes d'exploitation, il ne compte que les paquets qui ont été mis en correspondance par l'expression de filtre, que tcpdump ait lu ou non et les a encore traités, et sur d'autres systèmes d'exploitation, il ne compte que les paquets qui ont été mis en correspondance par l'expression de filtre et qui ont été traités par tcpdump);

paquets abandonnés par le noyau (c'est le nombre de paquets qui ont été abandonnés, en raison d'un manque d'espace tampon, par le mécanisme de capture de paquets dans le système d'exploitation sur lequel tcpdump s'exécute, si le système d'exploitation signale ces informations aux applications; sinon, il sera signalé comme 0).

Et il y a une entrée de liste de diffusion de 2009 expliquant:

Le numéro "paquets reçus par filtre" est le ps_recvnuméro d'un appel à pcap_stats(); avec BPF , c'est le bs_recvnombre de la BIOCGSTATS ioctl. Ce décompte inclut tous les paquets qui ont été remis à BPF; ces paquets peuvent toujours être dans un tampon qui n'a pas encore été lu par libpcap (et donc non remis à tcpdump), ou peuvent être dans un tampon qui a été lu par libpcap mais pas encore remis à tcpdump, afin qu'il puisse compter les paquets qui ne sont pas signalés comme "capturés".

Peut-être que le processus est tué trop rapidement? Il existe également un -c Nindicateur indiquant à tcpdump de se terminer lorsque les Npaquets ont été capturés.

Étant donné que votre problème semble assez spécialisé, vous pouvez également utiliser libpcapdirectement ou via l'une des centaines de liaisons de langage .

À votre question, puisque tout ce que vous obtenez sont les packages capturés dans le capture.capfichier, vous pouvez simplement regarder les pistes où il n'est pas vide et les examiner, c'est-à-dire, euh, compter les lignes?

tcpdump -r capture.cap | wc -l

Il y a probablement une meilleure façon d'utiliser libpcap pour renvoyer le nombre d'entrées dans le fichier de capture ...