[Winpcap-users] Captured packets buffered and not returned to the
guy at alum.mit.edu
Thu Dec 11 00:30:07 GMT 2008
On Dec 10, 2008, at 3:28 PM, Oliver Zheng wrote:
> I'm using WinPcap in an application to capture packets, but it seems
> that calls made to pcap_next() do not return immediately when a
> packet is received. The timeout is set to 0 (blocking indefinitely).
> The packets seem to be buffered in some location, so that in order
> to see a packet that just arrived, I have to capture a lot more
> packets for that packet to be flushed to my application. I am
> comparing my results to that of Wireshark, which seems to display
> packets immediately as they are received.
> Does anyone know what could be causing it
To quote the WinPcap documentation of pcap_open_live():
"to_ms specifies the read timeout in milliseconds. The read timeout is
used to arrange that the read not necessarily return immediately when
a packet is seen, but that it wait for some amount of time to allow
more packets to arrive and to read multiple packets from the OS kernel
in one operation. Not all platforms support a read timeout; on
platforms that don't, the read timeout is ignored. A zero value for
to_ms, on platforms that support a read timeout, will cause a read to
wait forever to allow enough packets to arrive, with no timeout."
Windows is a platform that supports a read timeout (the text in
question appears to have come from the libpcap documentation; libpcap
is a multi-UN*X-platform library for capturing network traffic, and
WinPcap is a port of that library to Windows plus a driver to provide
access to NDIS for that library).
This means that the read will block for as long as it takes to fill up
WinPcap's buffer (or *BSD/Mac OS X's BPF buffer, or Solaris's DLPI
buffer), so you will not see any packets until the buffer fills up.
> and how it can be fixed?
Wireshark does not say "block indefinitely"; it specifies a timeout,
so that if the specified number of milliseconds pass before the buffer
fills, the read will complete even though the buffer isn't full.
More information about the Winpcap-users