On Feb 1, 2010, at 8:44 AM, Carter Bullard wrote:
> Gentle people,
> I also am seeing similar behavior with libpcap-1.0.0 on Snow Leopard (10.6.2).
> Seems that this just started very recently, possible with the upgrade to
> 10.6.2
> but not sure about that.
>
> In my application, which uses pcap_dispatch() in non-blocking mode, and uses
> select() to be notified when to read all available packets,
Whether select() works correctly with BPF devices depends on the version of the
OS you're using. It works in "newer" versions of *BSD, for various values of
"newer" (I don't have a complete list handy, but the fix went into FreeBSD in
4.6); it works in "no" version of OS X, for the simplest value of "no". :-)
The problem is that a select(), in the OSes where it doesn't work, doesn't
start a timer, so the wakeup occurs *only* when the store buffer in the kernel
fills up.
The workaround is to
1) put the BPF descriptor into non-blocking mode;
2) pass the desired timeout (same as was specified in pcap_open_live()
or pcap_set_timeout()) as the timeout for select() (or, if you're already using
a timeout for select(), pass the minimum of the timeout you want and the
desired BPF timeout);
3) read from the BPF device with pcap_dispatch() (or pcap_next() or
pcap_next_ex()) regardless of whether select() says it has anything to read or
not;
as that'll mean you'll check it periodically - and the read will just return -1
with EAGAIN if there are no packets available and return what packets are
available if some are.
That's not new in Snow Leopard, however; that's been the case since Day One.
(And, yes, there's a bug filed on that.)
> Is any additional information I can provide to assist?
If you're already doing that workaround, is your program running 32-bit or
64-bit?-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
