guyharris
commented
11 years ago Submitted by guy_harris
No, it's due to fixing OS X bug 5729372; the behavior you're seeing in Snow Leopard is what you're supposed to be seeing on all systems that use BPF for packet capturing, including OS X and {Free,Net,Open,DragonFly}BSD. (Well, not on AIX, but AIX's BPF is weird.) FreeBSD had that bug a while ago, but it was fixed; OS X fixed it in 10.6. The bug is in BPF, so it affects all network adapters; it is not 802.11-specific, and thus has nothing to do with CoreWLAN (which is userland code, anyway, and thus doesn't affect capturing).
If, on an OS that uses BPF for packet capture, you want to see frames as soon as they arrive, you should turn "immediate mode" on for pcap's file descriptor, using BPF's BIOCIMMEDIATE ioctl - see the BPF(4) man page. You don't need to turn on non-blocking mode for that, although non-blocking mode should work.
Converted from SourceForge issue 2902860, submitted by chrism238
Using the following code:
http://www.csse.uwa.edu.au/~chris/trypcap.c
when libpcap-1.0.0 is compiled on OS-X 10.6 (Snow Leopard) with gcc 4.2.1, the call to pcap_setnonblock() appears to have no effect - the frames are dispatched in bursts of 100+ frames, taking a few seconds for each burst to arrive.
(I have also tried changing the non-blocking nature of pcap's file descriptor, using fcntl(fd, F_SETFL, O_NONBLOCK); all calls succeeded, but with no change to the symptoms).
Under OS-X 10.5 (Leopard) and gcc 4.0.1, the frames arrive immediately, one-at-a-time, as expected.
I am guessing that this is due to the introduction of CoreWLAN in 10.6?