PPCE struct pcap_pkthdr len vs Caplen

Question

Nous renifler des paquets en utilisant libpcap sur linux L'en-tête que nous obtenons sur chaque paquet ressemble:

struct pcap_pkthdr { 
     struct timeval ts;  /* time stamp */ 
     bpf_u_int32 caplen;  /* length of portion present */ 
     bpf_u_int32 len;  /* length this packet (off wire) */ 
}; 

Maintenant, Je crois comprendre que Caplen est la longueur des données nous avons capturé pendant que len est la longueur du paquet sur le fil. Dans certains cas (par exemple, lorsque le paramètre snaplen est trop bas lors de l'ouverture du périphérique pcap), nous pouvons capturer uniquement des parties du paquet, cette longueur sera 'caplen', alors que 'len' est la longueur d'origine. Ainsi, caplen devrait être égal ou inférieur à len, mais jamais supérieur à len.

Est-ce une bonne compréhension? Nous lisons caplen> len sur certaines machines

Answer 1

Votre compréhension est correcte, au moins basée sur la page man pcap.

caplen est la quantité de données à votre disposition dans la capture. len était la longueur réelle du paquet.

Je ne suis au courant d'aucun cas qui pourrait vous donner un caplen> len. Je les ai l'habitude d'être égaux étant donné que mon snaplen est suffisamment élevé.

Answer 2

Oui votre compréhension est juste Caplen est toujours moins que Len. Parfois, nous n'avons pas besoin de capturer le paquet entier. Mais pourquoi ne pas capturer le paquet entier donné une chance? Parce que dans un trafic réseau lourd, ce ne serait pas une bonne idée. N'avons-nous pas réellement perdre des données précieuses si nous ne capturons pas le paquet entier qui apparaît sur le fil? En fait, cela dépend de votre objectif, si vous voulez juste classer les paquets en fonction des protocoles et de l'application à laquelle ils sont destinés, vous avez besoin d'environ 14 octets (Ethernet) plus 20 octets (IP) + plus 20 autres (Tcp) Ainsi, vous n'avez besoin que de 54 octets de données pour classer les paquets en fonction des protocoles, donc beaucoup de charge et de temps sont économisés en réduisant la taille de traitement de pcappkthdr-> len à pcappkthdr-> caplen :)

Si les en-têtes de les paquets sont corrompus (ce qui signifie que si les valeurs d'en-tête sont en quelque sorte foirées) alors la longueur capturée sera plus grande que la longueur réelle du paquet.

Answer 3

Si caplen> len, c'est un bug; quelle version de libpcap utilisez-vous?