GETs from working when requesting IANA assignments files.
Replaced now unnecessary script arg retrieval logic with call to
stdnse.get_script_args.
Replaced count chars usage with string.len.
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.
