Here, the sizeof() function return the size of 'char *' instead of
INTF_NAME_LEN. I replaced the use of the latter function by INTF_NAME_LEN
(maximum size of the array intf_name). Here is the compiler warning output:
route-bsd.c:171:38: warning: sizeof on array function parameter will return
size of 'char *' instead of 'char [16]' [-Wsizeof-array-argument]
strlcpy(intf_name, namebuf, sizeof(intf_name));
Reported by multiple users on Windows 8.1 and Windows Server 2012 R2.
Seems to hang when the WinPCAP driver is accessed via OpenServiceA by
multiple processes at once. Users report that this change, which uses a
mutex to avoid concurrent access, fixes the hang.
Changes:
* Fix a collision of the name PS_NONE with a different constant in shlobj.h
* Update solution and project files for VS2013
* Update the NSIS installer to reference the VC 2013 redistributable
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.
There are some other #ifdefs that are used on other platforms, in which
code intf_name might nto be set but will continue to be an empty string
as before.
This is set to an empty string in all functions yielding routes,
particularly route_loop. The code to get the interface pertaining to a
route is different on different platforms, so must be added one by one.
The code setting the intf_name to an empty string is only tested on
Linux.
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.
