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".)
This is based on an idea from jah in
http://seclists.org/nmap-dev/2012/q1/655. Make ScanChooser and
DiffWindow take a flat list of scans, not a dict of names → scans, and
centralize the deduplication in ScanChooser.add_scan.
This was being done manually for various types of events, and not doing
it in every case was causing hard-to-find bugs. See the log messages for
r19970 in /nsock and r28292 in /nmap.
You could use "-e en0" to automatically add scope ids to your IPv6
addresses, so you didn't need the write "fe80::1234%en0". But this only
happened for the route_dst calculation, and could lead to later failures
in sendmsg when the address didn't have a scope id.
Remove the code from setup.py which augments the module search path with
install directories such as /usr/local/lib/python2.7/dist-packages/
because doing so is unnecessary, and can also be a potential security
risk if distributors do the initial install in world writeable
directories such as /tmp and then copy the resultant zenmap to
non-writeable dirs for installation on other systems.
On OS X, the code in route_loop in route-bsd.c can get a gateway
sockaddr_dl that looks like this:
$1 = {
sdl_len = 20 '\024',
sdl_family = 18 '\022',
sdl_index = 4,
sdl_type = 6 '\006',
sdl_nlen = 0 '\0',
sdl_alen = 0 '\0',
sdl_slen = 0 '\0',
sdl_data = '\0' <repeats 11 times>
}
route_loop would throw these out because there's no hardward address
there. This is a routing table entry that indicates that there is no
gateway, and that packets for this particular destination need to go on
interface #4. It corresponds to this type of line from netstat output:
Destination Gateway Flags Refs Use Netif Expire
192.168.0 link#4 UCS 2 0 en0
I've changed it so that instead of throwing out the entry, it creates an
all-zero address of the same type as the destination address, which is a
convention used (by Nmap at least) to indicate an on-link route.
This is a reversion of r26232 and r26230, which were themselves
reversions of r26201 and r26202 respectively, in
https://svn.nmap.org/nmap-exp/luis/nmap-os6@26232.
This code has gone back and forth a few times. Looking at it again, I
still think this way is more correct. At any rate, the other way
demonstrably leads to rare assertion failures (which are protecting
against a nonsensical subtraction with an all-zero timeval).
This is designed to solve the following problem: On Solaris 10 (maybe other
platforms), doing a select on a pcap fd works, in that it returns true when
there are frames available to be read. However, after finding the fd selectable
and calling pcap_dispatch (or pcap_next, etc.), libpcap may read more than one
frame and buffer them internally. This means that later calls to select will
return false. So there may be a frame to be read, but you can't know without
calling pcap_dispatch to check, and that blocks indefinitely (on Solaris) if
you're wrong.
The way this works is that we do a non-blocking read on the pcap fd to see if
there is anything available. If not, we do a select with a timeout as usual.
(The select is to enforce the timeout and prevent spinning CPU by repeatedly
trying non-blocking reads.)
I don't know if this phenomenon affects other platforms than Solaris 10
(more specifically, platforms using DLPI for libpcap). This same thing may be
safe or necessary on other platforms. But I have limited it to Solaris for now.
Solaris 11 uses BPF, not DLPI, for libpcap, but we can unconditionally follow
this code path on Solaris because BPF pcap fds can't be selected on.
