setsockopt() call that uses a pointer to some uninitialized memory. The
error message is the following:
==22214== Syscall param socketcall.setsockopt(optval) points to
uninitialised byte(s)
==22214== at 0x62F774A: setsockopt (syscall-template.S:82)
==22214== by 0x4E33B85: ??? (in /usr/lib/libpcap.so.1.0.0)
==22214== by 0x4E33D0D: ??? (in /usr/lib/libpcap.so.1.0.0)
==22214== by 0x432253: nsock_pcap_set_filter (in /usr/local/bin/nping)
==22214== by 0x432557: nsock_pcap_open (in /usr/local/bin/nping)
==22214== by 0x4295FF: ProbeMode::start() (in /usr/local/bin/nping)
==22214== by 0x40B2E1: main (in /usr/local/bin/nping)
This patch adds a simple memset() call that makes the warning dissapear.
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.
that they are not the default, remove duplicate dummy fules for them,
and combine the modification with an existing one for Flex/Bison removal
in NMAP_MODIFICATIONS.
ltmain.sh, and missing from subdirectories. Autoconf automatically looks
in the parent directory for these files. I had to copy the files
depcomp, ltmain.sh, and missing into the root of the source tree.
