I'm using the SharpPcap + PacketDotNet libraries to process some .pcap files and came across a bug in the way the timestamps are calculated.
Take this Timeval property, which is something along these lines:
PosixTimeval Timeval
{
DateTime Date;
ulong Seconds;
ulong MicroSeconds;
}
The problem is as follows: Suppose you have a trace open in Wireshark with one of the packets with a timestamp of "0.002". Once you open it within one of your programs, it retrieves the packet and its Timeval is setup such that Seconds = 0
and MicroSeconds = 002 = 2
. This is done under the hood, so there is no way to avoid it as far as I can tell.
My question is if that problem is common to other libraries (and maybe all of them?) who manipulate the pcap file format, which I think are built around the same collection of c/c++ functions, or if this is a problem only with the ones I'm using.