[Winpcap-users] RE: Packet timestamp strangeness (Richard Hansen)

Fri Jun 30 14:34:34 GMT 2006

I have worked with Ethereal/WinPCAP extensively in a large application.
I've had to analyze countless packet captures looking at the timing of
incoming and outgoing packets (my application both sends and receives
packets - does an entire protocol). To make things work I had to queue
some of the outgoing packets and put in a delay between packets in the
order of micro seconds. I have no reason to doubt the time stamp of the
packets that are captured - looks very accurate down to the us level. 

Take a close look at the initial set up of the adapter (pcap_open or
pcap_open_live function) - the read timeout parameter is critical to
what you are trying to do. The lowest value of 1 ms might not be fast
enough for you. Check the documentation - if set to 0 this might return
immediately on every packet.

Try running your packet capture application in real time mode as well. I
don't know how to do this in C++ but I did this in my .NET application
and it made an enormous difference.

--------------------------------------------------------

Mark Buchanan

Senior Engineer, Controls Systems
Giffels Associates Limited

Mark.Buchanan at giffels.com |  T 416 675 9750 Ext. 5253  |  F 416 798 5559  |  giffels.com

    This communication is intended solely for the addressee(s) and contains information that is privileged, confidential
    and subject to copyright. Any unauthorized use, copying, review or disclosure is prohibited. If received in error,
    please notify us immediately by return e-mail.

--------------------------------------------------------

-----Original Message-----

From: winpcap-users-bounces at winpcap.org
[mailto:winpcap-users-bounces at winpcap.org] On Behalf Of
winpcap-users-request at winpcap.org
Sent: Friday, June 30, 2006 8:01 AM
To: winpcap-users at winpcap.org
Subject: Winpcap-users Digest, Vol 15, Issue 24

Send Winpcap-users mailing list submissions to
	winpcap-users at winpcap.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.winpcap.org/mailman/listinfo/winpcap-users
or, via email, send a message with subject or body 'help' to
	winpcap-users-request at winpcap.org

You can reach the person managing the list at
	winpcap-users-owner at winpcap.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Winpcap-users digest..."

Today's Topics:

   1. Packet timestamp strangeness (Richard Hansen)

----------------------------------------------------------------------

Message: 1
Date: Fri, 30 Jun 2006 01:26:14 -0400
From: "Richard Hansen" <pcap-ri at scientician.org>
Subject: [Winpcap-users] Packet timestamp strangeness
To: <winpcap-users at winpcap.org>
Message-ID: <006701c69c05$b5d3bd40$0201a8c0 at reno>
Content-Type: text/plain;	charset="us-ascii"

Hi all,

I'm having trouble determining how the packet timestamp is calculated,
and I'm wondering if someone would be so kind as to enlighten me.  I
spent a good amount of time poring over the source code, but I'm not
familiar enough with the internals of WinPcap to understand what's going
on (I even saw some assembly code (!) in a function that I suspected
might be related to setting the timestamp).

I'm writing a proxy program that will likely be dealing with latency
sensitive applications.  I'm concerned that packets will become stale
when my system is too loaded to pull them out of the kernel buffer
rapidly.  I'm trying to insert some code at the very beginning of my
pcap_loop callback function that gets the current time, compares it with
the packet timestamp, and drops the packet if the difference is above
some user-configurable threshold.

Unfortunately, I'm getting significant inaccuracies when I calculate the
time difference.  The reported difference between packet timestamp and
current time ranges between negative (!) ~600us and positive ~10ms, with
~7ms being typical.  I know that anything over about 1.5ms can't be
right because I implemented a simple ping reply application that
dissects ICMP echo requests arriving via WinPcap and generates ICMP echo
replies.  Pinging from another box on the LAN shows about 1.5ms round
trip time.  Therefore, the actual time difference must be ~1.5ms minus
the amount of time it takes to dissect the ICMP packets and construct a
reply minus the time spent on the wire.

I'm getting the current system time by using GetSystemTimeAsFileTime and
then correcting for Microsoft's use of January 1, 1601 as epoch.  Of
course the system time can bounce around due to something like NTP, but
I figured it wouldn't change very often.  What I would really like is a
function like pcap_getcurrenttime() that returns the current time using
whatever method pcap is using to set the timestamp.

Here's a sample callback function that illustrates how I'm calculating
the time difference:

void callback(u_char* param, const struct pcap_pkthdr *header, const
u_char *pkt_data) { #define EPOCH_OFFSET (__int64)11644473600000000LL
    FILETIME FileTime;
    __int64 packetTime = (__int64)((header->ts.tv_sec
        * (__int64)1000000LL) + header->ts.tv_usec + timeout);
    GetSystemTimeAsFileTime(&FileTime);
    currentTime = (__int64)(((((ULARGE_INTEGER*)(&FileTime))->QuadPart)
        / 10) - EPOCH_OFFSET);
    fprintf(stderr, "Time difference: %lli\n", currentTime -
packetTime);

    /* ICMP echo reply code goes here */
}

Does anyone have any suggestions on how I can improve timing accuracy?

Thank you!
Richard

------------------------------

_______________________________________________
Winpcap-users mailing list
Winpcap-users at winpcap.org
https://www.winpcap.org/mailman/listinfo/winpcap-users

End of Winpcap-users Digest, Vol 15, Issue 24
*********************************************