an older, slower packet capture mechanism on Linux. Before Linux
2.6.27, the packet ring mechanism uses different-sized kernel
structures on 32- and 64-bit architectures, so a 32-bit program will
not run correctly on a 64-bit kernel. The older mechanism does not
have this flaw.
upstream (git://bpf.tcpdump.org/libpcap). This is a workaround for the
BIOCSRTIMEOUT bug in 10.6, 10.6.1, and 10.6.3 that doesn't work for
non-integer timeouts. A symptom of being affected by the bug is Nmap
haning forever at the first call to pcap_next. 10.6.2 was somehow not
affected.
This alone still doesn't solve the problem; I still have to make the
default --with-libpcap=included for 64-bit OS X.
The source comment is informative:
/*
* XXX - Mac OS X 10.6 mishandles BIOCSRTIMEOUT in 64-bit userland - it
* takes, as an argument, a "struct BPF_TIMEVAL", which has 32-bit
* tv_sec and tv_usec, rather than a "struct timeval".
*
* If this platform defines "struct BPF_TIMEVAL", we check whether the
* structure size in BIOCSRTIMEOUT is that of a "struct timeval" and, if
* not, we use a "struct BPF_TIMEVAL" rather than a "struct timeval".
* (That way, if the bug is fixed in a future release, we will still do
* the right thing.)
*/
commit 43acbb77a8e0b3346b574b3e28793de2d6985e69
Author: Guy Harris <guy@alum.mit.edu>
Date: Sun Oct 11 11:05:46 2009 -0700
Work around an annoying Snow Leopard BPF bug that causes sub-second
timeouts not to work in 64-bit userland code (Snow Leopard's GCC builds
64-bit by default on 64-bit machines).
looked like:
./configure: line 6651: syntax error near unexpected token `in'
./configure: line 6651: ` for ac_header in'
configure: error: ./configure failed for libpcap
Example: http://seclists.org/nmap-dev/2010/q1/444
The problem is a bogus empty test in the libpcap/configure.in. It
was actually fixed by libpcap in SVN back in 2008, but there hasn't
been a release since then :(. They seem to still be actively developing,
just not making releases. Sigh.
