The exceptions are the calls in ncat/ncat_connect.c and
nping/EchoServer.cc. Ncat doesn't have an option for the interface, and
I think Nping's -e option is only meant to apply to probes, not to the
echo server listener.
This was an old library removed in r2811 and r2812, of which a few
traces remained.
I don't know the purpose of this in nbase_misc.c:
if(sd != 501) // Hack related to WinIP Raw Socket support
ioctlsocket (sd, FIONBIO, &one);
For some reason (probably by imitation of nmap_getservbyport), protocol
numbers, which are byte values 0–255, had htons called on them after
being read from nmap-protocols. On little-endian platforms, this turned
them into integers 0x0100, 0x0200, 0x0300, etc.
protocol_table is supposed to be an array of 256 linked lists, linking
all the protocol names of the same number. Because of the above htons
conversion, all protocols mapped to bucket 0 on lookup instead. Perhaps
in an attempt to work around this broken lookup, all protocols were
inserted into bucket 0 on init; all other buckets were empty. This
worked on little-endian platforms, but on big-endian platforms where
htons is a no-op, all protocol numbers but 0 mapped to an empty linked
list.
Remove all the htons stuff and just look things up by integers. Use the
same mapping on initial insertion and on lookup, so that the buckets are
acutally populated.
This was noticed by hejianet.
http://seclists.org/nmap-dev/2012/q3/1005
These aren't getting regenerated even with "aclocal --force"; I think
it's because there is nothing to put in them. Running "aclocal
--verbose" shows that all the required macros are in acinclude.m4 files:
aclocal: saw macro PCAP_IS_SUITABLE
aclocal: saw macro RECVFROM_ARG6_TYPE
aclocal: saw macro PCAP_IS_SUITABLE
aclocal: saw macro CHECK_IPV6_IPPROTO_RAW
aclocal: saw macro APR_FIND_APR
aclocal: ../acinclude.m4 is already included by configure.ac
aclocal.m4 is autogenerated, so running aclocal would remove the
m4_include of acinclude.m4.
The exceptions are at the top of the source tree and in nsock/src, where
an acinclude.m4 lives; aclocal notices it there and automatically adds
an inclusion to the end of aclocal.m4, so no inclusion is needed in
configure.ac.
Besides the confusingness of the nodns argument being negatively
phrased, it had the value 0 in every existing call. Split out the nodns
special case into a separate function resolve_numeric.
This also has the side effect of changing the number of parameters to
the resolve function, which will cause a compile error for any calls I
might have missed changing when I changed the return code meaning in the
previous commit.
Ncat has its own copy of resolve, which obeys the global o.nodns rather
than a parameter. I'm leaving that alone for now. But give it the same
resolve_internal function, and make resolve call it with different flags
depending on the value of o.nodns.
The only error we can have apart from a getaddrinfo error is a list of
zero addresses; return EAI_NONAME in that case.
This unfortunately inverts the truth value of the return code of
resolve; 0 now means success.
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'
EchoServer.cc:1403:25: warning: variable ‘loopret’ set but not used [-Wunused-but-set-variable]", by simply mimicing the other error handling around nsock_loop elsewhere.
utils_net.cc:1114:7: warning: variable ‘res’ set but not used [-Wunused-but-set-variable] warnings by catching the return values of res and if they indicate failure at a lower level return OP_FAILURE
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
Resolving item from todo list:
o [Nping] The --safe-payloads option should be default (though we
should keep it for backward compatability). We could then introduce
--include-payloads for cases where they are desired.
-Documentation has not been updated.
If you have trouble updating after this revision you need to follow
these instructions. You have probably just seen an error like this:
svn: URL 'svn://svn.insecure.org/nping' of existing directory 'nping'
does not match expected URL 'svn://svn.insecure.org/nmap/nping'
This is caused by the replacement of SVN externals.
Here's what you need to do. First, save any local changes you might have
in the nping, nsock, nbase, ncat, and zenmap directories. (For example
by running "cd nping; svn diff > ../nping.diff".) If you don't have any
local changes you can skip this step.
Then run these commands:
rm -rf nping/ nsock/ nbase/ ncat/ zenmap/
svn update
svn cleanup
If all else fails, you can just delete your whole working directory and
check out anew:
svn co --username guest --password "" svn://svn.insecure.org/nmap
There may be further discussion in the mailing list thread at
http://seclists.org/nmap-dev/2011/q4/303.
