The IPv6 loopback interface on AIX has both IFF_BROADCAST and IFF_LOOPBACK set. Checking IFF_BROADCAST first erroneously makes it appear as an Ethernet device.
On AIX this test was passing even though this error happened on
compiling:
netutil.cc: In function 'int my_pcap_get_selectable_fd(pcap_t*)':
netutil.cc:870:34: error: 'pcap_get_selectable_fd' was not declared in this scope
On AIX, config.h defines _LARGE_FILES. This interacts badly with other
includes generated at the top of scanner.c, leading to errors like this:
In file included from scanner.c:2784:
/usr/include/unistd.h:171: error: conflicting types for 'lseek64'
/usr/include/unistd.h:169: error: previous declaration of 'lseek64' was here
In file included from /usr/include/unistd.h:746,
from scanner.c:2784:
/usr/include/sys/lockf.h:64: error: conflicting types for 'lockf64'
/usr/include/sys/lockf.h:62: error: previous declaration of 'lockf64' was here
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.
directories that nmap will search, e.g. ~/.nmap/nselib $NMAPDIR/nselib
/usr/share/nmap/nselib etc.
Resolves Daniel Miller's request [1].
[1] http://seclists.org/nmap-dev/2011/q3/817
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.
Mac OS X appears to have a new address convention that I can't find
documented. The link-local address fe80:4::X:X:X:X stands for
fe80::X:X:X:X%en0, if en0 is the interface with index 4. (I.e., it would
be fe80::X:X:X:X%4 on Windows.) The number 4 could be different numbers.
The interface addresses seem to be stored with these pseudo-zone IDs at
a low level, because they appear that way when they come from libdnet.
This is what "nmap --iflist" shows:
lo0 (lo0) fe80:1::1/64 loopback up 16384
en0 (en0) fe80:4::xxxx:xxxx:xxxx:xxxx/64 ethernet up 1500 XX:XX:XX:XX:XX:XX
The OS X network tools seem to hide this. This is what "ifconfig" and
"netstat -rn -f inet6" show:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
en0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::xxxx:xxxx:xxxx:xxxx%en0 prefixlen 64 scopeid 0x4
fe80::1%lo0 link#1 UHLI lo0
fe80::xxxx:xxxx:xxxx:xxxx%en0 XX:XX:XX:XX:XX:XX UHLI lo0
(Not the "scopeid 0x4".) Also, if you use one of these addresses, it
magically transforms into one without the pseudo-ID (getaddrinfo does
this):
$ ping6 fe80:4::1234
PING6(56=40+8+8 bytes) fe80::xxxx:xxxx:xxxx:xxxx%en0 --> fe80::1234%en0
$ ping6 fe80:1::1234
PING6(56=40+8+8 bytes) fe80::1%lo0 --> fe80::1234%lo0
This translation is messing up our netmask comparisons for the purpose
of routing. If you use a normal link-local address starting with fe80:0,
then it doesn't compare equal with the fe80:4/64 interface address. If
you try to use the 4, then getaddrinfo turns it into fe80:0 anyway, and
the comparison still fails.
So for this reason I added a canonicalize_address function, which calls
getnameinfo on an address, then calls getaddrinfo on the returned
string, to mangle an address the same way the OS would do it. One would
hope this is a no-op in cases other than the one I have described.
Now "nmap --iflist" shows:
lo0 (lo0) fe80::1/64 loopback up 16384
en0 (en0) fe80::xxxx:xxxx:xxxx:xxxx/64 ethernet up 1500 XX:XX:XX:XX:XX:XX
