This is the default behavior of the WinPcap device driver. In order to always get the packets as soon as they arrive in the buffer, you must use packet.dll, setting mintocopy=0 (see http://winpcap.polito.it/docs/man/html/group__packet32.html#a12) and readtimeout=0 (see http://winpcap.polito.it/docs/man/html/group__packet32.html#a19).
Also in this way, with 3.01a you will not probably obtain the result you expect, since I discovered a glitch that avoids the correct unblocking of the read event in some situations (mintocopy=readtimeout=0 is one of them). Future versions of WinPcap will contain a fix for this problem. Loris > > I'm writing an app that watches packets going over the net to my handheld > iPAQ. My app is running on a standard Windows XP machine - everything's > connected using a wireless LAN with D-Link adapter cards. > > My application is capturing packets OK, but they seem to be buffering up - > like I have to click Refesh 3-5 times before enough data is queued, then my > callback gets called saying there are packets available - then I get 10-30 > packets. I've set the snapcount to various sizes - like 65536, 1500, 1530, > trying for something that will cause the callback to occur for each packet, > but it still seems to be buffering a bunch of packets before calling back. > > I'm using the 3.01 alpha version, in case this is the problem. I'm also > using promiscuous mode. > > Thanks > Rich > > > > ================================================================== > This is the WinPcap users list. It is archived at > http://www.mail-archive.com/[EMAIL PROTECTED]/ > > To unsubscribe use > mailto: [EMAIL PROTECTED] > ================================================================== > ================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/ To unsubscribe use mailto: [EMAIL PROTECTED] ==================================================================
