N'importe qui avait de l'expérience avec les bibliothèques de manipulation * .pcap?

Question

J'utilise les bibliothèques SharpPcap + PacketDotNet pour traiter certains fichiers .pcap et j'ai rencontré un bug dans la façon dont les horodatages sont calculés.

Prenez cette propriété timeval, qui est quelque chose le long de ces lignes:

PosixTimeval Timeval 
{ 
    DateTime Date; 
    ulong Seconds; 
    ulong MicroSeconds; 
} 

Le problème est la suivante: Supposons que vous ayez une trace ouverte dans Wireshark avec l'un des paquets avec un horodatage de « 0,002 ». Une fois que vous l'ouvrez dans un de vos programmes, il récupère le paquet et son Timeval est configuré tel que Seconds = 0 et MicroSeconds = 002 = 2. Ceci est fait sous le capot, donc il n'y a aucun moyen d'éviter autant que je sache. Ma question est si ce problème est commun aux autres bibliothèques (et peut-être à toutes?) Qui manipulent le format de fichier pcap, qui, je pense, sont construites autour de la même collection de fonctions c/C++, ou si c'est un problème seulement avec ceux que j'utilise.

Answer 1

Je suis l'auteur de sharppcap/packet.net.

Quel est le bogue que vous voyez avec les valeurs d'horodatage? La conversion que vous avez mentionnée semble correcte. 0,002 secondes est de 2 millisecondes. Les valeurs d'horodatage doivent correspondre à l'horodatage unix complet lorsque le paquet a été capturé. Certes, un timeval de 0,002 n'a pas de sens en temps absolu, seulement un temps relatif.

Je vais ajouter un test unitaire à sharppcap pour valider le timeval du paquet s'il n'y en a pas déjà un.