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
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]
addr_stob didn't handle the special case of the sa_len member of
struct sockaddr being equal to 0 and accessed unrelated memory past
the end of the sockaddr. A symptom of this was the fatal error
nexthost: failed to determine route to ...
which was caused by the default route being assigned a netmask other
than 0.0.0.0.
