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.
GetAdaptersAddresses is supposed to return ERROR_BUFFER_OVERFLOW and set
len to the required size when len is too small. So normally we would
call the function once with a small len, and then again with the longer
len. But, on Windows 2003, apparently you only get ERROR_BUFFER_OVERFLOW
the *first* time you call the function with a too-small len--the next
time you get ERROR_INVALID_PARAMETER. So this function would fail the
second and later times it is called.
So, make the first call using a large len. On Windows 2003, this will
work the first time as long as there are not too many adapters. (It will
still fail with ERROR_INVALID_PARAMETER if there are too many adapters,
but this will happen infrequently because of the large buffer.) Other
systems that always return ERROR_BUFFER_OVERFLOW when appropriate will
enlarge the buffer if the initial len is too short.
An IPMP interface is a special kind of interface made up of other
interfaces. The other interfaces are hidden by default unless this flag
is passed to ioctl(SIOCGLIFCONF). This allows me to scan over an IPMP
interface in a simple setup.
First try SIOCGLIFFLAGS with an IPv4 socket, then again with an IPv6 socket if that fails. Use that same socket for the other ioctl queries.
Avoid adding an IPv6 alias address that is the same as an IPv6 primary address. This is the same as an existing check in the IPv4 case.
Fix a loop exit boundary condition check.
On OS X, the code in route_loop in route-bsd.c can get a gateway
sockaddr_dl that looks like this:
$1 = {
sdl_len = 20 '\024',
sdl_family = 18 '\022',
sdl_index = 4,
sdl_type = 6 '\006',
sdl_nlen = 0 '\0',
sdl_alen = 0 '\0',
sdl_slen = 0 '\0',
sdl_data = '\0' <repeats 11 times>
}
route_loop would throw these out because there's no hardward address
there. This is a routing table entry that indicates that there is no
gateway, and that packets for this particular destination need to go on
interface #4. It corresponds to this type of line from netstat output:
Destination Gateway Flags Refs Use Netif Expire
192.168.0 link#4 UCS 2 0 en0
I've changed it so that instead of throwing out the entry, it creates an
all-zero address of the same type as the destination address, which is a
convention used (by Nmap at least) to indicate an on-link route.
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.
MAC address matched the expected address, and if so, take that as a preliminary
match before checking the description string for a stronger match. But if
retrieving the the MAC address failed completely, it was still being accepted
as a preliminary match, and would prevent later matches with only the MAC
address from being accepted.
matches, but keep searching in case there's an interface where both the
hardware address and description string match.
Matching only on the hardware address is not sufficient, because several
interfaces will have the same address in the case of interface teaming.
See the log message for r17542.
But this revision broke interface matching for Luis MartinGarcia and Rob
Nicholls. For Luis, the call to PacketRequest with OID_GEN_FRIENDLY_NAME
was failing. For Rob, the friendly name differed slightly from the
description provided by libpcap. This change makes a hardware address
match good enough but will prefer a description match too.
eth_get_pcap_devname as a wrapper.
In addition to the hardware address check, add a check of the textual interface
descriptions in order better to distinguish interfaces. It appears to me that
the pcap description (pdev->description) is the same as what is returned by a
call to PacketRequest with an OID of OID_GEN_FRIENDLY_NAME, so that's what I'm
comparing. That differs from OID_GEN_VENDOR_NAME, which is what you get in
ifrow.bDescr from GetIfTable.
We've found that simply comparing hardware addresses is not enough when using
Windows "teamed" (link-aggregated) interfaces. In a simple example, two NICs
are teamed together, leading to three interfaces visible to libdnet: the two
physical NICs and the virtual teamed interface. All three of these have the
same MAC address. What was happening was the eth0 interface was being assigned
to one of the physical NICs, packets were sent over it, but the replies were
not necessarily coming back to the same physical NIC.
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]
