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.
This was a hassle to support on AIX (several broken implmentations) and
the move to a more portable solution (using autoconfig macros) was also
troublesome. Upon review, nse_fs.cc only uses directory and link
functions, so large files support shouldn't matter. Stripping it out.
nse_fs.cc was forcing large files support, and it was broken on AIX due
to this GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
Now we let autoconf handle setting the appropriate defines, and also
check for this particular bug before defining.
$ svn merge -r r33518:r33513 .
and removed added scripts to the script.db.
The branch needs further refinement/testing for Windows and Mac before merging
into the trunk. There is also the latent EOF bug which is giving performance
issues.
Further work on the branch will continue in Devin's latest branch:
/nmap-exp/devin/nmap-libssh2
Currently, this just uses Python's unittest module to autodiscover
tests, which may skip some, but is better than nothing. TODO: move tests
to their own module and let the zenmap_check target test them directly.
When configuring --without-ncat, "make check" was trying to run Ncat's
test suite. This commit splits the check target into ncat_check and
nsock_check, and makes each conditional on that subsystem's configure
status.
These appear not to have any effect any more. They were initially used
to conditionally compile and link some files with replacements for
standard library functions, but seem not to have been used after r828
("Moved to nbase system for compatability funcs").
John Spencer reported that musl libc doesn't automatically include
<stdlib.h>, as Glibc does, so the configure check was wrongly failing.
conftest.c: In function 'main':
conftest.c:35:5: error: implicit declaration of function 'exit'
Solaris 11 uses BPF packet capture rather than DLPI, which requires
different handling in many cases. The new preprocessor symbol tells when
this is the case; it is additional granularity on top of SOLARIS.
The lack of this was causing PCAP_IS_SUITABLE to fail on Arch Linux, at
least. I think that in some cases this caused both -L../libpcap and
-lpcap to be added to the linker line, which could cause an error
because of the need to link with -lnl. (We check for -lnl when
--with-libpcap=included is used (since r23163), but the PCAP_IS_SUITABLE
failure went around this check and allowed linking with the included
libpcap without checking whether -lnl is required.)
Here are reported build failures and responses:
http://seclists.org/nmap-dev/2011/q3/449http://seclists.org/nmap-dev/2011/q4/33http://seclists.org/nmap-dev/2012/q1/369
On AIX this test was passing even though this error happened on
compiling:
netutil.cc: In function 'int my_pcap_get_selectable_fd(pcap_t*)':
netutil.cc:870:34: error: 'pcap_get_selectable_fd' was not declared in this scope
svn merge --ignore-ancestry svn://svn.insecure.org/nmap@26621 svn://svn.insecure.org/nmap-exp/luis/nmap-os6
This is the IPv6 OS detection branch. "nmap -6 -O" works now, though at
this point it only prints fingerprints and not OS guesses, because we
need to collect more submissions.
