views:

77

answers:

1

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.

A: 

Hello.

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.

Chris Morgan