Doesn't happen often, but as the message says, certain Solaris zones can
cause problems here. This message is more informative than the previous
"socket troubles in Init"
This change restores the control flow of handling connect() return and
error values. This shouldn't result in any real changes, but makes it
simpler to see the differences introduced in r33185.
Since the refactor in r33185, getting a good response for a host during
a ping scan can remove all outstanding probes for that host, since we
already know the host is up. This broke the existing iteration in some
cases. I could force the crash with: nmap -sn -PS80-89 scanme.nmap.org
Now we check explicitly for an empty list each time through the loop.
Consolidate connect-scan status and errno checking
Previously, the return value and socket errors from the connect() call
were checked in two different places: immediately after the call, and
then later as the sockets were select()ed over. This led to a divergence
of logic, so the immediate checking failed to set state reasons or
contribute to timing. This commit puts all such checking into a single
function, handleConnectResult, so further improvements will not diverge
again.
Previously, the return value and socket errors from the connect() call
were checked in two different places: immediately after the call, and
then later as the sockets were select()ed over. This led to a divergence
of logic, so the immediate checking failed to set state reasons or
contribute to timing. This commit puts all such checking into a single
function, handleConnectResult, so further improvements will not diverge
again.
In sendConnectScanProbe, the usual method is to start a non-blocking
connect() and then do select() on the sockets until we get a result. On
some platforms and in some circumstances, connect() either blocks or
comes back immediately. We handled this by setting the port state
appropriately, but we didn't set the reason, yielding results like "Host
is up, received no-response" and "80/tcp open http no-response"
proposal. This only affects Nmap's root directory. We might also need to
modify the code which autogenerates Nmap's source code files such as IPv6
fingerprinting code.
Only FD_SET and FD_CLR were available. Added a FD_ISSET equivalent.
Implemented them as static inline instead of macros for consistency.
These functions abort() if the FD number is higher than FD_SETSIZE
(except on windows where no check is performed).
Using TIMEVAL_MSEC_SUBTRACT can lead to integer overflow when the times
are far apart (such as epoch (0) or uninitialized timeval and "now").
Instead, calculate the "deadline" and use TIMEVAL_AFTER to test.
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
Remainder of Chris Johnson's patch from
http://seclists.org/nmap-dev/2013/q3/296.
Previously, Nmap could match replies that came in response to an
original probe, with one of the retransmissions of the probe. One effect
was that latency would be measured to be smaller than it should. Chris
Johnson summarized the problem and showed how to reproduce it at
http://seclists.org/nmap-dev/2013/q3/113.
DiabloHorn on #nmap noticed that Nmap was ignoring ICMP Time Exceeded
messages while trying to map firewall rules using --ttl.
get_pcap_result() was handling ICMP type 3 (Destination Unreachable),
but not type 11 (Time Exceeded). Now ports that elicit this response
will be marked filtered (to be consistent with existing Connect scan
behavior) and will report time-exceeded from (IP) for the reason.
This was not a common issue, since host discovery already accounted for
it. Port scans would only be affected when skipping host discovery.
At high scan rates, there was nothing to prevent trying to set or clear
socket descriptors above FD_SETSIZE, which is usually around 1024. I got
a reliable assertion failures with the command
nmap -sT -p- --min-rate 100000 scanme.nmap.org
The problem only affected -sT scans. A similar protection was added to
Nsock in r15808.
This code was quite old (dating from r854 in 2000) and may not serve a
purpose anymore. Let's try removing it.
Apart from being obsolete, the code had a race condition where the
connection could be closed with a RST before getpeername was called,
leading to a fatal error message.
There was one case where we previously didn't fatal, in nse_dnet.cc.
Move the fatal calls out of nmap_raw_socket and into the calling scope,
with the exception of the one in nse_dnet.cc.
The problem was reported by Rob Nicholls.
http://seclists.org/nmap-dev/2012/q4/186
Importing the whole std namespace caused a problem with Clang and the
punning of bind and std::bind.
http://seclists.org/nmap-dev/2012/q4/58
The Web's opinion of "using namespace std" also seems to be more against
than for.
Using o.magic_port, which is usually used for our source address, or
otherwise is somewhat randomly generated, doesn't make sense here.
Instead, use the same destination ports that we use for host discovery:
80 for TCP and SCTP, and 40125 for UDP.
http://seclists.org/nmap-dev/2012/q3/663
If we get a reply that doesn't pass the simple comparison using the
current value of USI->seqmask, then ignore it. Previously we emitted the
message "Bad Sequence number from host %s.\n" and allowed the reply to
match any probe. This only matters when using -g because otherwise we
encode that information in the source port. I think we have addressed
what was mentioned in the TODO comment in r15986. Allowing promiscuous
matching, as was done before, causes the same spurious closed port issue
that was addressed in r29686.
