The Linux-specific SO_BINDTODEVICE sockopt causes packets to be sent on
a specific interface, in cases where merely setting the source address
does not uniquely determine the interface.
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
Because in_addr is stored in network byte order, this function could
extract the octets in MSB-to-LSB order or in LSB-to-MSB order. This
didn't matter in the case of resolved names, because the same order was
used when generating the octet array and later when matching against it.
But the function parse_ipv4_ranges, which handles literal IPv4
addresses, always uses octet[0] as the MSB, so comparisons failed in
later matching.
As it was, the code worked on little-endian architectures but didn't on
big-endian.
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.
