The packet construction had a bug that made it more effective in at
least one case for me. Weilin had supplied a 16-byte destination options
buffer, including some random bytes from a packet capture. But the
length of buffer was set incorrectly in the packet, making it look like
it was 8 bytes instead of 16. Therefore the expected ICMPv6 packet
started in the middle of the buffer, making it appear to have a
type/code of 254/24 instead of 128/0 as expected.
I tried setting the proper length, while keeping the invalid destination
option, but then stopped getting a Parameter Problem response. I also
tried setting a proper destination options buffer with no invalid
options, followed by ICMPv6 with type/code of 128/0, and again got no
response. It appears that I get a response only when both of these
conditions are satisfied: 1) an invalid destination option exists, and
2) the ICMPv6 type is unknown. This is against OS X.
The probe was being effective by accident, but now I've simplified it
and documented these strange conditions.
This breaks any hosts that might have ignored the invalid destination
option (which they shouldn't do) and replied to the echo request. But we
have targets-ipv6-multicast-echo for that.
Using the builtin Windows copy preserves Windows ACLs. Without this, the
copied DLLs don't have their original ACLs, and something about this
causes the program to abort with error 0xc0000022.
Some subset of these was causing the nmap project to always appear out
of date when beginning debugging. At any rate, they don't appear to be
necessary. Compare r25068.
This is set nonzero when there is a scope identifier at the end of
an IPv6 address, like fe80::a8bb:ccff:fedd:eeff%eth0 or
fe80::a8bb:ccff:fedd:eeff%1 on Windows. When this happens, we look up
the interface by index and then act as if it was the interface given by
-e. (But -e always has precedence over this.)
This is set nonzero when there is a scope identifier at the end of
an IPv6 address, like fe80::a8bb:ccff:fedd:eeff%eth0. When this
happens, we look up the interface by index and then act as if it was the
interface given by -e. (But -e always has precedence over this.)
This is set nonzero when there is a scope identifier at the end of an
IPv6 address, like fe80::a8bb:ccff:fedd:eeff%eth0. When this happens, we
add an rtattr with type RTA_OIF to request a particular outgoing
interface.
In my tests, this does the right thing when the address is in fact the
assigned address of the interface; the interface becomes lo instead of
the physical interface name.
A RST/ACK can only be matched to a SYN or FIN. A bare RST cannot
be matched to a SYN or FIN.
Matthew Stickney and Joe McEachern found cases where this caused replies
to be missed (specifically, RST/ACK in reponse to a NULL probe) and also
found standards justification for hosts returning RST/ACK in such a
situation.
that look like POSIX collating symbols ("[.xyz.]"). John Hutchison
discovered this error caused by one of the match lines:
InitMatch: illegal regexp: POSIX collating elements are not supported
[Daniel Miller]
