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
On platforms supporting sa_len, NEXTIFR would skip over sa_len bytes
starting at the beginning of ifr_addr, and assume that was the end of
the struct. (The idea being that a large address such as a sockaddr_in6
could overflow the nominal struct boundary.) This logic was wrong when
there was something else in the union bigger than sa_len; we would
increment into somewhere in the middle of the same struct.
This exhibited itself on NetBSD, where struct ifreq has a
sockaddr_storage member in its internal union:
struct ifreq {
char ifr_name[IFNAMSIZ]; /* if name, e.g. "en0" */
union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
struct sockaddr_storage ifru_space;
No, we skip over sa_len bytes, or to the nominal end of the struct,
whichever is larger.
Unix Network Programming gets this wrong too; in figure 17.8 they do
ptr += sizeof(ifr->ifr_name) + max(sizeof(struct sockaddr), ifr->ifr_addr.sa_len);
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'
smb.get_os already returns something that is fairly well structured, so
basically return that. Keep the "os" and "lanmanager" fields separate,
though they are combined as "os (lanmanager)" for normal output. Combine
"time" and "timezone" into a single "date" output.
This takes a broken-down date table, as produced by os.date("*t"), and
converts it into an integer number of seconds since the epoch UTC,
interpreting it as a time in a given time zone. Simply passing a date
table to os.time is not good enough, because os.time always assumes the
date table represents a local time; i.e., you will get different results
from running os.time({year=2012,month=1,day=1,hour=12,min=0,sec=0})
depending on what time zone you run it in.
The new version improves the detection mechanism to cover PHP environments with .htaccess files and adds spidering to locate password protected resources automatically.
This happens on Windows when two sockets bind to the same local port and
connect to the same remote port on a remote host. I tried this on Linux;
Linux prevents the second bind from succeeding.
http://seclists.org/nmap-dev/2012/q2/513
Otherwise WinSock error numbers are not understood; you get "Unknown
error" instead of "Only one usage of each socket address
(protocol/network address/port) is normally permitted." for example.
It is possible to send so quickly that we start getting EAGAIN on sends.
In listen mode, this means that some sends can get lost. This patch,
adapted from one by Alex Weber, makes sockets blocking for the duration
of the send. This is not as nice as retrying the send through an event
mechanism, but should at least be correct.
http://seclists.org/nmap-dev/2012/q3/670
Compare a similar patch in r13552, which applied to --exec mode.
