Per Windows API docs: "do not pass a handle returned by GetModuleHandle
to the FreeLibrary function. Doing so can cause a DLL module to be
unmapped prematurely."
Fixed a bug that prevented Nmap from finding any interfaces when one
of them had the type ARP_HDR_APPLETALK; this was the case for
AppleTalk interfaces. However, This support is not complete
since AppleTalk interfaces use different size hardware addresses
than Ethernet. Nmap IP level scans should work without any problem,
please refer to the '--send-ip' switch and to the following thread:
http://seclists.org/nmap-dev/2013/q1/214
This bug was reported by Steven Gregory Johnson on IRC.
of them had the type ARPHDR_INFINIBAND; this was the case for
IP-over-InfiniBand interfaces. However, This support is not complete
since IPoIB interfaces use 20 bytes for the hardware address, and
currently we only report and handle 6 bytes.
Nmap IP level scans should work without any problem, please refer to
the '--send-ip' switch and to the following thread:
http://seclists.org/nmap-dev/2012/q3/642
This bug was reported by starlight.2012q3.
of them had the type ARPHDR_IEEE80211; this was the case for wireless
interfaces operating in access point mode. This bug was reported by
Sebastiaan Vileijn.
http://seclists.org/nmap-dev/2012/q3/986
On platforms supporting sa_len, NEXTIFR would skip over sa_len bytes
starting at the beginning of ifr_addr, and assume that was the end of
the struct. (The idea being that a large address such as a sockaddr_in6
could overflow the nominal struct boundary.) This logic was wrong when
there was something else in the union bigger than sa_len; we would
increment into somewhere in the middle of the same struct.
This exhibited itself on NetBSD, where struct ifreq has a
sockaddr_storage member in its internal union:
struct ifreq {
char ifr_name[IFNAMSIZ]; /* if name, e.g. "en0" */
union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
struct sockaddr_storage ifru_space;
No, we skip over sa_len bytes, or to the nominal end of the struct,
whichever is larger.
Unix Network Programming gets this wrong too; in figure 17.8 they do
ptr += sizeof(ifr->ifr_name) + max(sizeof(struct sockaddr), ifr->ifr_addr.sa_len);
This type is used by OpenVZ venet interfaces. We "handle" such an
address type just by blanking the MAC address field.
Lack of support for this type of interface was preventing Nmap from
working on certain systems.
http://seclists.org/nmap-dev/2012/q2/763
An earlier message about this same type of interface is
http://seclists.org/nmap-dev/2009/q3/303
at least one of them is in the monitor mode. The fix was to define the
ARP_HRD_IEEE80211_RADIOTAP 802.11 radiotap header identifier in the
libdnet-stripped code. Network interfaces that are in this mode are used
by radiotap for 802.11 frame injection and reception. The bug was
reported by Tom Eichstaedt and Henri Doreau.
http://seclists.org/nmap-dev/2012/q2/449http://seclists.org/nmap-dev/2012/q2/478
[Djalal Harouni, Henri Doreau]
This is a (hopefully temporary) workaround for these virtual interfaces
on Solaris. They don't work for Nmap because they don't allow packet
sniffing, but you can use one of the physical interfaces they're
composed of.
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.
a struct of the same name in <netinet/sctp.h>. This caused a
compiliation error when Nmap was compiled with an OpenSSL that had
SCTP support. [Olli Hauer, Daniel Roethlisberger]
o Made eth_get_pcap_devname compare interface descriptions as well as
MAC addresses when assigning interface names like eth0 on Windows.
Only comparing MAC addresses failed in the case of "teamed"
interfaces, when three interfaces (two physical, one virtual) could
have the same hardware address.
versions of OpenSolaris (I tested snv_134) also support PF_PACKET, but
not in an entirely compatible way. The configure check was making the
build use eth-linux.c, which doesn't compile under OpenSolaris. This
change makes OpenSolaris fall back to eth-dlpi.c, which works. The
report about this was sent by Darren Reed.
than one string of digits. Joe Dietz reported that an interface with
the name e1000g0 was causing the error message
Warning: Unable to open interface e1000g0 -- skipping it.
on Solaris 9. [David]
which have been merged to the upstream libdnet repository and thus
do not have to be re-applied when the libdnet version included with
Nmap is updated in the future.
