There are some other #ifdefs that are used on other platforms, in which
code intf_name might nto be set but will continue to be an empty string
as before.
This commit fixes two different bugs:
(1) First in some situations Nmap will only see routes that are attached
to the device that handles the default route.
(2) On boxes without a default route, Nmap will not see any route.
These two bugs are caused by sysroutes_dnet_find_interfaces() logic
which will use only the geteway to match interface addresses.
To fix this, first check the current route and see if the gateway was set
otherwise use the destination address to match the address of an
interface.
This is set to an empty string in all functions yielding routes,
particularly route_loop. The code to get the interface pertaining to a
route is different on different platforms, so must be added one by one.
The code setting the intf_name to an empty string is only tested on
Linux.
of them had the type ARPHDR_INFINIBAND; this was the case for
IP-over-InfiniBand interfaces. However, This support is not complete
since IPoIB interfaces use 20 bytes for the hardware address, and
currently we only report and handle 6 bytes.
Nmap IP level scans should work without any problem, please refer to
the '--send-ip' switch and to the following thread:
http://seclists.org/nmap-dev/2012/q3/642
This bug was reported by starlight.2012q3.
of them had the type ARPHDR_IEEE80211; this was the case for wireless
interfaces operating in access point mode. This bug was reported by
Sebastiaan Vileijn.
http://seclists.org/nmap-dev/2012/q3/986
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
rpc.Comm.Connect was trying to bind to 424 reserved ports, which is
overkill. Since nsock doesn't do an actual bind(2) call until
socket:connect for TCP, that meant up to 424 connect calls, each of
which is currently leaking a socket. This commit contains 3 fixes:
1. Add nmap.new_socket calls for non-privileged code path that were
moved inside the privileged loop to originally address the leak.
2. Check for TIMEOUT on each of the TCP connect calls and abandon the
Connect, avoiding many timeouts.
3. Try 10 random reserved ports (from 1 to 1024) instead of 400+.
Should be good odds of finding one unused, even when lots of threads are
trying (though empirical results would be helpful). Also, this should
reduce load since thread n won't need to fail n-1 bind attempts.
It appears that connecting more than one with the same nse_nsock socket
leaks socket descriptor. For example,
local s = nmap.new_socket()
s:connect(host, port) --> TIMEOUT
s:connect(host, port) --> TIMEOUT
s:close()
leaks a socket descriptor, the one used in the first connect. Nsock
should really take care of this, but let's do this workaround because
rpc-grind has been causing problems due to using the above pattern:
http://seclists.org/nmap-dev/2012/q3/864http://seclists.org/nmap-dev/2012/q3/872http://seclists.org/nmap-dev/2012/q3/949
The difficulty is that the rpc library will tolerate around 400 of those
timeouts per RPC connection, which leads to rapidly running out of
descriptors.
There was a reverse table that was meant to map keys to their position
in the order table, to make it easy to table.remove an entry from order.
But removing something from order would shift the indices of all
following elements by 1, and those elements were not updated
correspondingly in the reverse table. Instead, do a linear lookup for
the the element to remove from order, after checking that the element
exists at all.
http://seclists.org/nmap-dev/2012/q3/905
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.
It was nmap_update_svn_cmdline_create_auth_baton, but should be
nmap_update_svn_cmdline_setup_auth_baton.
This was missed in r27746, which otherwise was making the same change.
This was noticed by John Spencer.
http://seclists.org/nmap-dev/2012/q3/942
