We count a drop for congestion control purposes if we receive a response
to a retransmitted probe, because that means that the reply to the
original probe was dropped. However, we weren't taking into account that
we are at the same time receiving a positive response, and should
increase the window accordingly. There are now three things that can
happen:
Response to first probe: ACK
Response to retransmission: DROP, then ACK
Probe timeout: DROP
distance now counts the number of hops including the final one to
the target, not just the number of intermediate nodes. The IPv6
distance calculation already worked this way. [David]
The comment in struct_ip.h explains the reasoning for this. The AIX C library
uses #defines that change the names of members of struct ip, and conflict with
some existing code. (Notably struct ip_hdr in libdnet and IPv4Header::h in
libnetutil.) We can still use the AIX files if we include <netinet/ip.h> after
this other code has been preprocessed. That's hard to enforce when
<netinet/ip.h> is included from another header file; this new file allows
including it always late, and only where needed.
svn merge --ignore-ancestry svn://svn.insecure.org/nmap@26621 svn://svn.insecure.org/nmap-exp/luis/nmap-os6
This is the IPv6 OS detection branch. "nmap -6 -O" works now, though at
this point it only prints fingerprints and not OS guesses, because we
need to collect more submissions.
Heretofore we have always extracted teh destination address directly
from the packet contents. But the raw packet bytes do not contain enough
information in one case: IPv6 link-local addresses. For those we really
need the scope ID, and for that we must pass this information all the
way down.
Before this, I got "no route to host" on OS link-local addresses. I
think that it was working on Linux only on accident, by the OS picking a
default interface or something.
We should have the multiprotocol version be the main version, with
IPv4-only code being a noted exception. Also these functions are almost
the same so one can call the other.
returning floating-point seconds. Everywhere o.TimeSinceStartMS was
called, the return value was being divided by 1000.0, which had the same
effect but would overflow when the difference exceeded about 25 days
(2^31 milliseconds). This patch is by Daniel Miller.
