Re: libpcap on Mac Os X 10.6 Snow Leopard

[Guy Harris <guy () alum mit edu>]

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.