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.
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.
This restores the previous behavior of these functions, which was broken
in r24127, which itself was fixing another bug.
r24127 solved the problem of --data-length appending zeroes, not random
data, to ICMP and IGMP packets. But in doing so, it added a check that
the data argument is not NULL. OS detection uses a data argument of
NULL, expecting these functions to fill in zeroes in this case. The
result of this was that the IE probes were being sent with empty
payloads instead of 120 and 150 bytes.
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.
unspecified and causes a segmentation fault on Android Bionic libc.
Vlatko fixed the bug in his Android binaries and it was first reported
by @alexismm2.
resolve except that it returns all resolved addresses. Use this new
function to resolve IPv4 addresses instead of gethostbyname in
TargetGroup.cc. The gethostbyname code assumed that only IPv4 addresses
would be returned. If the resolver returned IPv6 addresses, TargetGroup
would blindly copy the first four bytes of the IPv6 address into the
IPv4 struct. This was first reported by Mats Erik Andersson at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584301; he also
suggested the fix.
allow the sa_len to increase the size of the current structure, not
decrease it below sizeof(struct ifreq). Doing it this way makes it work
on NetBSD. This technique more or less matches that used in Unix Network
Programming, 3rd Edition, section 17.6. The old implementation was
likely incorrect, though it happened to work on FreeBSD.
DLT_LINUX_SLL, as well as the DLT_EN10MB that was formerly supported.
This type is used on some interfaces where Linux doesn't reliably retain
the link-layer header, and when capturing on the "any" device. On such
interfaces, you would get the error
read_arp_reply_pcap called on interfaces that is datatype 113 rather than DLT_EN10MB (1)
For more on this datalink type, see
pcap-linktype(7)
http://wiki.wireshark.org/SLL
I tested this by hacking scan_engine.cc to use the "any" device:
--- scan_engine.cc (revision 16972)
+++ scan_engine.cc (working copy)
@@ -4882,7 +4882,7 @@
}
}
- USI->pd = my_pcap_open_live(Targets[0]->deviceName(), 100, (o.spoofsource)? 1 : 0, pcap_selectable_fd_valid()? 200 : 2);
+ USI->pd = my_pcap_open_live("any" /*Targets[0]->deviceName()*/, 100, (o.spoofsource)? 1 : 0, pcap_selectable_fd_valid()? 200 : 2);
if (USI->ping_scan_arp){
/* Some OSs including Windows 7 and Solaris 10 have been seen to send their
ARP replies to the broadcast address, not to the (unicast) address that
I had to use a newer version of libpcap from git. The 1.0.0 that we ship
has a bug that keeps "any" from working. You would get SIOCGIFHWADDR: No
such device.
table is exactly the same as the address. This is how it appears to work on Mac
OS X. Now there are three ways for an address to be directly connected:
1. Gateway address is 0.0.0.0 (Linux).
2. Gateway address is the same as local interface address (Windows).
3. Gateway address is the same as the destination address (Mac OS X).
interface addresses and netmasks.
Before, route_dst worked like this:
1) Check destination address against all interfaces, with special-case
handling for local addresses.
2) Check destination address against routing table.
Now it works like this:
1) Check destination address against local addresses.
2) Check destination address against routing table.
3) Check destination address against all interfaces.
This allows a routing table entry to override an interface, for example
in this configuration:
************************INTERFACES************************
DEV (SHORT) IP/MASK TYPE UP MAC
eth0 (eth0) 192.168.0.21/24 ethernet up 00:00:00:00:00:00
**************************ROUTES**************************
DST/MASK DEV GATEWAY
192.168.0.3/32 eth0 192.168.0.1
192.168.0.0/24 eth0
192.168.0.3 will not be considered directly connected, but will have its
traffic routed through 192.168.0.1.
The logic for determining when an address is directly connected has
changed. Instead of considering an address directly connected whenever
it matches an interface netmask, we consider it so when the gateway
address is 0.0.0.0 or when the gateway address is exactly equal to the
interface address. The proper way to do this would be to look at the "G"
flag from the routing table, but libdnet doesn't retain that.
This establishes a more regular syntax for some options that disable
phases of a scan:
-n no reverse DNS
-Pn no host discovery
-sn no port scan
Also, the -sP was possibly misleading because the 'P' suggests "ping
scan," when you can now do more than just pinging when you disable port
scanning. For example, -sC -sn and -sn -Pn --traceroute make sense.
being used, and this leaves the door open for non-Ethernet encapsulation
of ARP packets, in particular the Linux "cooked" socket encapsulation
that can in some cases be used by libpcap.
entries:
o [NSE] Raw packet sending at the IP layer is now supported, in addition to
the Ethernet sending functionality. Packets to send start with an IPv4
header and can be sent to arbitrary hosts. [Kris]
o [NSE] Added the ipidseq script to classify a host's IP ID sequence numbers
in the same way Nmap does. This can be used to test hosts' suitability for
Nmap's Idle Scan (-sI), i.e. check if a host is an idle zombie. This is
the first script to use the new raw IP sending functionality in NSE. [Kris]
o [NSE] Added the function nmap.is_privileged() to tell a script if, as far
as Nmap's concerned, it can do privileged operations. For instance, this
can be used to see if a script should be able to open a raw socket or
Ethernet interface. [Kris]
o [NSE] Added the function nmap.get_ports() to allow a script to iterate
over a host's port tables matching a certain protocol and state. [Kris,
Patrick]
connections in tcpip.cc. socket_strerror works with Winsock error codes whereas
plain strerror returns "Unknown error".
However, the error string for what is probably the most common error code,
WSAEWOULDBLOCK, is the big ugly "A non-blocking socket operation could not be
completed immediately.". Add a special case to use "Operation now in progress"
for that specific error.
