We probably want a more explicit handling of the case where we get an
ARP response to a request that we did not send (system's own, or another
Nmap scan running at the same time). In any case, this ought to solve
the crashes reported as #1797 and #1764.
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).
