On Jun 22, 2004, at 2:04 AM, Gianluca Varenni wrote:
Hi. I think the "problem" is that such event is signalled by the kernel only
when a certain amount of data is present in the buffer (the so called
"mintocopy"). Such event is NOT signalled when the timeout you set with
pcap_open (or pcap_open_live) is elapsed;
I.e., it's bug-for-bug compatible with older BSDs. :-)
In older versions of FreeBSD and OpenBSD, all versions of Mac OS X, and, I think, all versions of NetBSD, a "select()" or "poll()" on a BPF device with a timeout will indicate that the BPF device is readable only if the buffer fills up, not if the timeout expires. (Newer versions of FreeBSD and, I think, OpenBSD fix this.)
The workaround for this is to put the BPF device descriptor into non-blocking mode, use the BPF timeout as the timeout in the "select()" or "poll()" call, and, when the "select()" or "poll()" returns, read from the device regardless of whether "select()" or "poll()" says it's ready to be read from.
Doing so in WinPcap would set the read timeout to -1 with "PacketSetReadTimeout()" (that's what "pcap_setnonblock()" would do, use the BPF timeout in a "WaitForSingleObject()", "WaitForMultipleObjects()", "MsgWaitForSingleObject()", or "MsgWaitForMultipleObjects()" call, and try to read from the pcap_t regardless of whether the WaitFor call says you can do so.
Would that work? I.e., would reading from the device before the timer expires cause whatever packets are available to be returned by "PacketReceivePacket()" - on both Windows OT (95,98,Me) and NT (NT 4.0,2000,XP,2003 Server)? (I would presume so, if, on both of those platforms, "PacketReceivePacket()" itself does a timed "WaitForSingleObject()", as per your mail.)
================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/
To unsubscribe use mailto: [EMAIL PROTECTED]
==================================================================
