message once per host, not one per hostgroup. Include the IP address and
tryno in the message. It now looks like
Warning: 64.13.134.52 giving up on port because retransmission cap hit (0).
This was suggested by Chris Clements.
This always goes to XML and grepable output. It goes to normal in
interactive output in verbose mode. The format for printing a down host
is changed slightly:
Nmap scan report for 1.1.1.1 [host down]
LOG_PLAIN or LOG_STDOUT depending on whether o.resolve_all was set, and
just always print to LOG_PLAIN like we do all the other output. This was
the cause of a discrepancy between interactive and normal output
reported at http://seclists.org/nmap-dev/2009/q4/230.
appear in reference fingerprint" and the code used to support it. This
happens all the time with submitted fingerprints and is nothing to worry
about. I don't want to be distracted from other warnings. This code was
only used by the OS fingerprint integration tools, not by Nmap itself.
if (tcp_rpc_socket > max_sd)
max_sd = tcp_rpc_socket;
The condition is always true because max_sd is initialized to -1 and that block
of code is entered only if tcp_rpc_socket > -1. It looks like the kind of thing
that would be managing a large set of sockets for select, but here we're only
selecting on one socket at a time. This was suggested by Lionel Cons.
The script provides detection when version probes fail, but will default to
the value provided the version probes if that value is more precise. The
script also detects the server platform and database instance name.
[Tom]
now a script is limited in parallelism to working on one socket at any
time. A script can now create a worker thread that will be capable of
doing work on sockets in parallel with the parent script. See [1] for
more information.
This patch also comes with condition variables that are similar to
POSIX condition variables. They are used in the same fashion as
NSE's mutexes (nmap.mutex).
[1] http://seclists.org/nmap-dev/2009/q4/294
lookup. The hash table used linear probing which got very slow as the
hash table got full. Using std::map is about 10 times faster. The hash
table was slow enough that it took the majority of the time for me in an
ARP scan of a single address.
# nmap -sP 192.168.0.190
mac_prefix_init took 0.49261 s.
Nmap done: 1 IP address (1 host up) scanned in 0.59 seconds
# nmap -sP 192.168.0.190
mac_prefix_init took 0.04392 s.
Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds
The memory usage of std::map is probably greater. The hash table used
19037 pointers and about 13000 structures of size 8 (on a 32-bit
architecture), or about 176 KB. Assuming the map has left, right, and
parent pointers, and a red-black indicator per node, the usage is 16
bytes per prefix plus 8 bytes for the structure data, or 304 KB total.
But this makes fingerdiff so much faster, I want to leave it in place at
least until this round of OS integration is done.
because of a lack of responses. Otherwise there is no way for that
number to decrease after moving on to the next port, leading to an
infinite loop. Lionel Cons reported the problem and provided a debug log
at http://seclists.org/nmap-dev/2009/q4/364.
space, and there was one line of mostly blank space in the cloud of
fire. The cloud looks better without the blank space and also aligns
better with the mouth.
* Updated the way authentication works on smb -- it's significantly cleaner now
* smb-enum-shares.nse gives significantly better output now (it checks if shares are writable)
* Added a script that checks if smbv2 is enabled on a server
* Added smb-psexec, a script for executing commands on a remote Windows server. I also included some default scripts, a compiled .exe to run everything, and a ton of documentation (in the form of NSEDoc)
* Added 'override' parameters to some of the functions in smb.lua, which lets the programmer override any field in an outgoing SMB packet without modifying smb.lua.
* Lots of random code cleanups in the smb-* scripts/libraries
servers. Pass that to nsock_connect_udp instead of using
sizeof(sockaddr_storage). Mac OS X return EINVAL if the length is not what's
expected for the address family.
(*p & 0x40) == 0x40
But that doesn't check that the upper half of the byte is 4. It's true for 4,
5, 6, 7, 12, 13, 14, and 15. I changed it to
(*p & 0xF0) == 0x40
can be used in /etc/resolv.conf or with the --dns-servers option. The
parallel reverse DNS resolver still only support IPv4 addresses, but
it can look them up over IPv6. [Ankur Nandwani]
to control whether translations of man pages are installed (by default
they will be). Even though we're not using gettext for translations, I
tried to make this interface as similar as possible to the gettext
configuration interface. Use can use the environment variable LINGUAS to
control which man pages get installed if you don't want all of them, for
example LINGUAS="es de". The translated man pages are not yet committed.
o Removed IP ID matching in packet headers returned in ICMP errors.
This was already the case for some operating systems that are known
the IDs of sent IP packets. In rare cases of ID mangling, requiring
a match could cause replies to be ignored even after other tests had
shown them to be relevant. See http://seclists.org/nmap-dev/2009/q2/580
for an example of host order affecting scan results, caused by this
phonomenon. [David]
o Added some additional matching rules to keep a reply to a SYN probe
from matching an ACK probe to the same port, or vice versa, in ping
scans that include both scan types. Such a mismatch could cause an
ineffective timing ping or traceroute probe to be selected. [David]
test that was applied to packets returned in ICMP error messages.
Because some operating systems modify the IP ID outside of Nmap's
control, the apply_ipid_match function had a built-in heuristic whereby
it would deactivate itself (always return true) if this seemed to be
happening. What this meant in practice was that every time a successful
match was made, a counter was incremented, and if the ratio of
successful matches to successful matches was over 80%, IP ID matching
was enforced.
The matching and heuristic could cause relevant probes to be dropped in
some cases. See http://seclists.org/nmap-dev/2009/q2/665 for an example
of this and discussion. The IP ID match was always done in combination
with other tests; so even without it we are still dealing with a
relevant probe. The IP ID distinction could at best distinguish between
retransmissions of the same probe, and it was not necessary for that in
every case, such as with most TCP probes where we can use the SEQ field.
I thought this small benefit was not worth the risk of potentially
losing replies that we care about.
