The following features are disabled:
* monitor-mode sniffing of wireless interfaces on Linux, via libnl
* building shared libraries
* Bluetooth support
* usb support
* dbus capture support
Reported by multiple users on Windows 8.1 and Windows Server 2012 R2.
Seems to hang when the WinPCAP driver is accessed via OpenServiceA by
multiple processes at once. Users report that this change, which uses a
mutex to avoid concurrent access, fixes the hang.
Libpcap only needs libnl for monitor-mode sniffing. Disabling it lets us
not worry about which -lnl or -lnl-3 linker argument to include in our
own LIBS, so Nmap builds properly no matter whether libnl is present or
not.
bluetooth, usb, usb-can, and dbus sniffing. Dbus support caused a build
problem on CentOS 6.5. Would have preferred to pass these configurations
from our own configure script, but AC_CONFIG_SUBDIRS does not allow for
it.
The patch that moves "config.h" to the top of scanner.l (and hence
scanner.c) has to happen before the files are pregenerated, otherwise
there is an error on AIX:
In file included from scanner.c:2792:
/usr/include/unistd.h:171: error: conflicting types for 'lseek64'
/usr/include/unistd.h:169: error: previous declaration of 'lseek64' was here
I needed this to build with --with-libpcap=included on Linux 2.6.16,
otherwise I got this error:
gcc -g -O2 -O2 -fpic -I. -DHAVE_CONFIG_H -D_U_="__attribute__((unused))" -c ./pcap-usb-linux.c
./pcap-usb-linux.c: In function ‘probe_devices’:
./pcap-usb-linux.c:234: error: storage size of ‘ctrl’ isn’t known
./pcap-usb-linux.c:279: error: ‘USBDEVFS_CONTROL’ undeclared (first use in this function)
./pcap-usb-linux.c:279: error: (Each undeclared identifier is reported only once
./pcap-usb-linux.c:279: error: for each function it appears in.)
make[1]: *** [pcap-usb-linux.o] Error 1
commit a092bafeee07c97352d2c6d06780220286ab2db0
Author: Guy Harris <guy@alum.mit.edu>
Date: Tue Nov 30 15:52:45 2010 -0800
In test programs, just as in pcap-usb-linux.c, if we have
<linux/compiler.h> we (probably need to include it before including
<linux/usbdevice_fs.h>, otherwise the test may fail when it shouldn't.
commit b019cc06cb4fdc01f99a36581fe7b55e2533d663
Author: Guy Harris <guy@alum.mit.edu>
Date: Thu Nov 25 14:06:01 2010 -0800
Check whether we have <linux/compiler.h>.
Not all distributions have it in /usr/include; I guess the ones that
don't have it have versions of other kernel headers that don't require
it.
commit 0920898be2ede72baafa2a02e77ea223ecbe4f9a
Author: Guy Harris <guy@alum.mit.edu>
Date: Thu Nov 25 13:49:16 2010 -0800
Include <linux/compiler.h> before including <linux/usbdevice_fs.h>.
Some versions of the Linux kernel require that.
commit 85089fea5732acc004dcc7e6aebcb0510c37f675
Author: Guy Harris <guy@alum.mit.edu>
Date: Fri Jun 4 10:48:16 2010 -0700
Do filtering on USB and Bluetooth capturing.
Do the standard userland filtering on USB and Bluetooth captures, rather
than returning "success" when the filter is installed without doing
anything with the filter.
Also, squelch some "dereferencing type-punned pointer will break
strict-aliasing rules" warnings in pcap-bt-linux.c, by using memcpy
rather than pointer-casting.
On AIX, config.h defines _LARGE_FILES. This interacts badly with other
includes generated at the top of scanner.c, leading to errors like this:
In file included from scanner.c:2784:
/usr/include/unistd.h:171: error: conflicting types for 'lseek64'
/usr/include/unistd.h:169: error: previous declaration of 'lseek64' was here
In file included from /usr/include/unistd.h:746,
from scanner.c:2784:
/usr/include/sys/lockf.h:64: error: conflicting types for 'lockf64'
/usr/include/sys/lockf.h:62: error: previous declaration of 'lockf64' was here
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.
