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.
for file in `grep "* including the terms and conditions of this license text as well. \*" * -r --files-with-match `; do sed "s/\* including the terms and conditions of this license text as well. \*/* including the terms and conditions of this license text as well. */g" -i $file; done
The previous code to ignore down interfaces didn't account for implicit
routes that come from interface addresses and netmasks. You can force
the use of a route using a down interface with -e.
NStorm reported a failure of ARP ping scan on OpenVZ venet devices,
which don't have a MAC address and can't do ARP. We don't keep interface
flags such as NOARP at the target level, so check whether the interfaces
returned by libdnet are both INTF_TYPE_ETH and don't have
INTF_FLAG_NOARP set; otherwise call them "other" interfaces.
http://seclists.org/nmap-dev/2013/q1/349http://openvz.org/Virtual_network_device
Nping calls route_dst at least twice: once with a NULL device, and again
with the device learned from the first time. This interfered with the
code that automatically chooses a loopback interface for dests that are
the same as an interface address. For example, if you are 192.168.0.1,
and you are scanning 192.168.0.1, route_dst will tell you to use
interface "lo0" even though the interface of 192.168.0.1 may be "eth0".
route_dst was returning failure because the device name check was being
done before "eth0" got changed to "lo0".
This problem didn't show up on Linux because Linux uses
route_dst_netlink, which delegates the work to the kernel. But I could
reproduce on Linux by forcing the use of route_dst_generic.
This used to be used to hold the original argv before quashing with -q.
Now that -q is gone, it was just a copy of argv.
fakeargv was also causing Valgrind to complain about leaked memory. it
wasn't a real leak, but now it's out of the report anyway.
This is a refactoring of target parsing that stores different types of
target specifications as different classes. The eventual intention is to
allow easy iteration over each specification for the purpose of IPv6
multicast host discovery.
There was an embarrasing bug here added in r28874. In the second of
three calls to get_srcaddr, the interface was being indexed by an index
variable that, in this place, was actually an index into the routes
table. This would in general produce a nonsensical source address or
out-of-bounds access.
The symptom of this problem was the following error messages:
get_srcaddr: can't connect socket: The requested address is not valid in its context.
Failed to convert source address to presentation format!?! Error: Unknown error
The first showed that get_srcaddr failed, and the second was caused by
the bogus source address.
http://seclists.org/nmap-dev/2012/q3/859http://seclists.org/nmap-dev/2012/q4/59
When an interface doesn't have an address set, getInterfaceByName can
fail because it checks the address family. The fatal error message would
be something like
route_dst_netlink: can't find interface "tap0"
If we can't find an interface with a specific address family, fall back
with an AF_UNSPEC search.
http://seclists.org/nmap-dev/2012/q4/12
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.
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.
The second argument to RTA_NEXT was missing a dereference, so it was
changing the pointer rather than the integer pointed to. I got this
assertion failure with an IPv6 link-local address:
nmap: netutil.cc:3048: void add_rtattr_addr(nlmsghdr*, rtattr**, unsigned int*, unsigned char, const sockaddr_storage*): Assertion `((*len) >= (int)sizeof(struct rtattr) && (*rtattr)->rta_len >= sizeof(struct rtattr) && (*rtattr)->rta_len <= (*len))' failed.
This value gets clobbered after the netlink recvmsg. It was giving me a
bogus address family (234), which caused the call to getInterfaceByName
to fail:
Could not find interface wlan0 which was specified by -e
This seems to have been exposed by r29754. Specifying a source address
that is not on any actual route seems to result in a netlink query
result with 0 entries, and the changed value of rtm_family. (The fact
that there are no routes returned is not a problem, because we bail out
early when -e is given, now that getInterfaceByName works again.)
