Previously we always took the destination address from the packet
buffer, which failed for IPv6 link-local addresses because the packet
buffer does not contain the scope id.
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.
As well as being shorter, this prevents connecting using a different
address family (e.g., IPv6 rather than IPv4) compared to doing this:
http.get(host.targetname, port.number)
Patch by John Bond.
http://seclists.org/nmap-dev/2012/q2/637
This is what setTargetNextHopMAC already did, but the code change was
not copied here. This provided a way for NSE scripts to cause an
assertion failure:
local math = require "math"
local packet = require "packet"
function portrule(host, port)
return port.protocol == "udp"
end
function action(host, port)
local ip_raw = bin.pack("H", "60000000000d11ff")
.. host.bin_ip_src .. host.bin_ip
.. bin.pack(">S", math.random(32768, 65535)) .. bin.pack(">S",
port.number)
.. bin.pack("H", "000d8082") .. "hello"
local p = packet.Packet:new(ip_raw, #ip_raw)
p:udp_count_checksum()
local s = nmap.new_dnet()
s:ip_open()
s:ip_send(p.buf)
end
This would fail with the message "doArp can only handle IPv4 addresses"
when ip_send called getNextHopMAC. (Only with --send-eth.)
ssl-enum-ciphers was producing output against non-ssl services, listing
"least strength: strong" when there was no cipher matched. Fixed to
return nil in this case, and to clearly indicate when a protocol is
supported but does not support any of our ciphers (a very unlikely
situation! Had to artificially reduce attempted ciphers to test.)
Was crashing on unparseable dates (example: "2147483647Z"). Now the
exact string is placed in structured output when it cannot be
normalized. Also, the structured-format timestamp is used for Normal
output for consistency; no timezone offset was previously displayed.
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.)
--route-dst has been a useful debugging option, but it ran inline during
option processing and always used AF_UNSPEC to resolve names. Let it run
after options have been processed, so it can obey things like -6, -S,
and -e. Let it always resolve with o.af(), so you get different results:
nmap --route-dst scanme.nmap.org
nmap -6 --route-dst scanme.nmap.org
We previously restricted by destination address; do it for source
address as well. This can matter in some configurations.
http://seclists.org/nmap-dev/2012/q3/831
There still seems to be a problem with the wrong route being chosen with
--send-ip, but this patch is reported to work with --send-eth.
The script was checking the returned data, but not the status. When
status is false, data is actually an error message. So in case of a
timeout, the script was receiving nil, "TIMEOUT" and interpreting
"TIMEOUT" as a response from the server. It looked like this:
Discovered open port 1434/udp on 127.0.0.1
NSE: rpc-grind: RPC checking function response data is not RPC.
NSE: Target port 1434 is not a RPC port.
This was reported by Christopher Clements.
http://seclists.org/nmap-dev/2012/q3/685
