Solaris 11 uses BPF packet capture rather than DLPI, which requires
different handling in many cases. The new preprocessor symbol tells when
this is the case; it is additional granularity on top of SOLARIS.
Setting --min-parallelism without also setting --max-parallelism would
force the max parallelism to the same value. So, for example,
--min-parallelism=1 would also limit the max parallelism to 1. This
patch, based on one by Chris Woodbury, allows the max parallelism to
rise above this minimum, up to the maximum defined by each scan phase.
The Nsock select engine stores readiness information in a mask instead
of doing an FD_ISSET against the descriptor every time. This is a good
idea, but it removed a special case in the pre-engines code: in case
PCAP_CAN_DO_SELECT is not defined, we can't do FD_ISSET on the
descriptor because it is -1. Here we check for that occurrence and set
EV_READ in the mask so that a non-blocking pcap read can happen every
iteration.
There was a missing level of deference on the pointers, so a condition
was never true in normal use. The effect was that check_target could
return without haveing put something in *addr, the previous contents of
which would later be passed to getaddrinfo, causing a "Name or service
not known" error.
I was surprised when I found that Solaris 11 scanning works now. I
thought that it would require a change in the defines around
pcap_selectable_fd_valid, because it's valid for Solaris 10 and earlier
but not for Solaris 11. Why it started working was the
pcap_selectable_fd_one_to_one test added in r28319. As a side effect of
that function overrides pcap_selectable_fd_valid for all Solaris
releases, it makes changes in pcap_selectable_fd_valid unnecessary.
However it is indirect in the way it does it, so I'm adding a comment
explaining the situation and a hope that there is an easy change to make
pcap_selectable_fd_valid correct on its own.
Previously this would be omitted if the service was not otherwise
discovered, and the port it was on was not in nmap-services. (There was
not problem if the port was present in nmap-services with a name of
"unknown".)
