the drop counter in pcap_stats() shows the number packets rejected by the NPF driver's tap function because of lack of space in the kernel buffer.
A cause of the difference between the user and kernel counters could be that you have packets still to be processed by your application: the packets are buffered both in the driver and in libpcap, and pcap_stats() counts them before this buffering. I admit that 145K packets is quite a lot to be explained with buffering, but you could try to look at the counters when there's no network activity, and see if the situation improves.
Loris
----- Original Message ----- From: "David Chang" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 22, 2004 9:02 PM
Subject: [WinPcap-users] Re: difference in pcap_stats versus calls to callback routine.
Hi,
I'm using Winpcap 3.0 and comparing the number of times my callback routine gets called versus the number that pcap_stats() returns.
They are quite different.
For example, after running my application for 16 hours, the number of calls to my callback routine is: 5558989, but the number of packets received via pcap_stats() is: 5704481. That's a difference of 145492 packets. What are those extra packets that Winpcap sees but doesn't call the callback routine with?
Is there anything I've done in the application to be off this much?
Lastly, I think I might be dropping packets, but pcap_stats() tells me I'm not (0 packets dropped). I've already changed the kernel buffer to 2MB rather than 1MB. How accurate is pcap_stats() about dropping packets?
DC
================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/
To unsubscribe use mailto: [EMAIL PROTECTED]
==================================================================
