There is a special test that uses IP IDs to check if a presumed reply
from localhost is actually one of our own probes. However the test
didn't bail out ofter finding one of these matches, so a retransmission
(with a different IP ID) could match and look like a protocol reply from
localhost.
We should have the multiprotocol version be the main version, with
IPv4-only code being a noted exception. Also these functions are almost
the same so one can call the other.
returning floating-point seconds. Everywhere o.TimeSinceStartMS was
called, the return value was being divided by 1000.0, which had the same
effect but would overflow when the difference exceeded about 25 days
(2^31 milliseconds). This patch is by Daniel Miller.
number to guarantee it's nonzero (which some target hosts require) rather
than looping for new random numbers.
* ICMP ID values are unimportant, as long as they are nonzero
* The original code to get random numbers was exactly duplicated (new variable,
comment, loop, even whitespace) in the same function, so using a single
variable set initially (albeit differently) simplifies duplication
scan. ARP scan had a hardcoded initial timeout of 100 ms, which could be
lower than the minimum requested. The default minimum timeout is also
100 ms, so this has no effect if --min-rtt-timeout is not used.
a struct of the same name in <netinet/sctp.h>. This caused a
compiliation error when Nmap was compiled with an OpenSSL that had
SCTP support. [Olli Hauer, Daniel Roethlisberger]
flag) is received in response. This can be due to an extremely rare TCP feature
known as a simultaneous open or split handshake connection.
see http://nmap.org/misc/split-handshake.pdf
Added a reason code: ER_SYN and associated reason string: "split-handshake-syn".
being used, and this leaves the door open for non-Ethernet encapsulation
of ARP packets, in particular the Linux "cooked" socket encapsulation
that can in some cases be used by libpcap.
port is unknown, instead of -1. This makes it a better fit with the
other accessor functions. For those callers that need to know whether a
port is in the default state or not, add PortList::portIsDefault.
Having getPortState return -1 for ports in the default state would cause
the slightly wrong
Discovered unknown port 88/udp on 192.168.0.190 is actually open
to be printed instead of
Discovered open|filtered port 88/udp on 192.168.0.190 is actually open
changes. The first is that Port objects don't allocate memory for
service and RPC results unless that information is set. This reduces the
size of a bare Port from 92 to 40 bytes on my machine. The second change
is that PortList now has the notion of a "default port state," which is
the state of any ports that didn't receive a response. These ports don't
need an allocated Port object, which saves a lot of memory in scans
where most ports didn't get a response.
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.
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.
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.
