Anyone had any experience with *.pcap manipulation libs?
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.
I'm the author of sharppcap/packet.net.
What is the bug that you are seeing with the timestamp values? The conversion you mentioned seems correct. 0.002 seconds is 2 milliseconds.
The timestamp values should be the full unix timeval when the packet was captured. Certainly a timeval of 0.002 doesn't make sense as an absolute time, only a relative one.
I'll add a unit test to sharppcap to validate the packet timeval if there isn't one already.
精彩评论