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.
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.
Per-probe tryno and pingseq are encoded as offset from a the base source
port number. Previously this was fixed for all calls of ultra_scan,
which means that unrelated probes in different calls would use the same
source port number if they had the same tryno and pingseq. This could
cause erroneous results if a reply to a probe from a previous call was
delated and was received in the current call and interpreted as a legit
response.
This has no effect when o.magic_port_set is true (i.e., when -g or
--source-port is used).
http://seclists.org/nmap-dev/2012/q1/62http://seclists.org/nmap-dev/2012/q3/589
