From NTA-Wiki
arp-scan is a command-line tool for system discovery and fingerprinting.
It constructs and sends ARP requests to the specified IP addresses, and displays any responses that are received.
arp-scan allows you to:
Send ARP packets to any number of destination hosts, using a configurable output bandwidth or packet rate.
This is useful for system discovery, where you may need to scan large address spaces.
Construct the outgoing ARP packet in a flexible way.
arp-scan gives control of all of the fields in the ARP packet and the fields in the Ethernet frame header.
Decode and display any returned packets.
arp-scan will decode and display any received ARP packets and lookup the vendor using the MAC address.
Fingerprint IP hosts using the arp-fingerprint tool.
ARP (Address Resolution Protocol) is a protocol that determines the link-layer (layer-2) address for a given network layer (layer-3) address.
ARP is defined in
An Ethernet Address Resolution Protocol.
The ARP protocol is designed to allow it to be used for any link-layer and network-layer protocols. However in practice it is only used for Ethernet (including 802.11 wireless) and IPv4, and we assume these protocols throughout this document. IPv6 uses NDP (neighbour discovery protocol) instead, which is a different protocol.
ARP is a non-routable protocol, and can therefore only be used between systems on the same Ethernet network.
The diagram below shows an example ARP packet within an Ethernet frame:
ARP packet within an Ethernet frame
The Ethernet frame contains the MAC header followed by the ARP packet data.
Both the MAC header and ARP packet data consist of a number of fields, each of which contains sample data in hexadecimal and a field name. The field names in the ARP packet data are from . The numbers in multi-byte fields are in network byte order, or big endian, with the high value byte first.
In the diagram, the packet is an ARP request (ar$op = 0001) for the IP address 10.0.0.2 (ar$tpa).
It was sent from the system with MAC address 00:C0:9F:09:B8:DB (both MAC source address and ar$sha) and IP address 10.0.0.1 (ar$spa).
The packet is sent to the all stations broadcast address FF:FF:FF:FF:FF:FF (MAC destination address).
This packet is displayed by tcpdump as follows:
00:c0:9f:09:b8:db & ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 10.0.0.2 tell 10.0.0.1
And a raw hex dump of the packet, including the Ethernet MAC header is:
ff ff ff ff ff ff 00 c0 9f 09 b8 db 08 06 00 01
08 00 06 04 00 01 00 c0 9f 09 b8 db 0a 00 00 01
00 00 00 00 00 00 0a 00 00 02
The two tables below describe the fields in the Ethernet MAC header and the ARP protocol data.
Field NameSize (Bits)FunctionNotes
Dest Address48Frame destination addressBy default ARP requests are sent to the broadcast address ff:ff:ff:ff:ff:ff
Source Address48Frame source addressDefault is the address of the outgoing interface
Protocol Type16Ethernet protocol typeThe ARP protocol type is 0806
The length of the MAC header is 14 bytes (112 bits).
Field NameSize (Bits)FunctionNotes
ar$hrd16ARP Hardware TypeDefault is 0001 (Ethernet)
ar$pro16ARP Protocol TypeDefault is 0800 (IPv4)
ar$hln8Link Layer Hardware Address LengthDefault is 6 bytes (48 bits)
ar$pln8Network Protocol Address LengthDefault is 4 bytes (32 bits)
ar$op16ARP Opcode0001 for ARP Request or 0002 for ARP Reply
ar$sha48Sender Hardware AddressDefault is the address of the outgoing interface
ar$spa32Sender Network Protocol AddressDefault is the IP address of the outgoing interface
ar$tha48Target Hardware AddressDefault is zero for ARP requests
ar$tpa32Target Network Protocol AddressFor ARP requests, this is the IP address that we wish to find
The length of the ARP protocol data is 28 bytes (224 bits).
This is less than the minimum Ethernet data length of 46 bytes, so the ARP data will always be followed by at least 18 bytes of padding.
arp-scan can be used to discover IP hosts on the local network.
It can discover all hosts, including those that block all IP traffic such as firewalls and systems with ingress filters.
arp-scan works on Ethernet and 802.11 wireless networks.
It may also work with token ring and FDDI, but they have not been tested.
It does not support serial links such as PPP or SLIP, because ARP is not supported on them.
You will need to be root, or arp-scan must be SUID root,
that it uses to read and write Ethernet packets require root privilege.
If the system you are testing from has an address on the network you wish to scan, the simplest way to scan it is with a command similar to:
arp-scan --interface=eth0 --localnet
Here, --interface=eth0 represents the interface to use for scanning, and --localnet makes arp-scan scan all possible IP addresses on the network connected to this interface, as defined by the interface IP address and netmask. You can omit the --interface option, in which case arp-scan will search the system interface list for the lowest numbered, configured up interface (excluding loopback).
The network interface name depends on the operating system you are using, the network type (Ethernet, Wireless Etc), and for some operating systems on the interface card type as well.
In this document, the interface name eth0 is used for examples except where a different network type is being discussed.
All arp-scan options have both a long form like --interface=eth0 and a corresponding short form like -I eth0.
I always use the long form in this document for clarity.
Here is an example showing arp-scan being run against the local network:
$ arp-scan --interface=eth0 --localnet
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.5.2 with 256 hosts (http://www./tools/arp-scan/)
192.168.1.1
00:c0:9f:09:b8:db
QUANTA COMPUTER, INC.
192.168.1.4
00:02:b3:bb:5c:09
Intel Corporation
192.168.1.3
00:02:b3:bb:66:98
Intel Corporation
192.168.1.5
00:02:a5:90:c3:e6
Compaq Computer Corporation
192.168.1.6
00:c0:9f:0b:91:d1
QUANTA COMPUTER, INC.
192.168.1.8
00:02:b3:3d:13:5e
Intel Corporation
192.168.1.9
00:02:b3:bb:66:bd
Intel Corporation
192.168.1.10
00:02:b3:63:cd:16
Intel Corporation
192.168.1.12
00:02:a5:de:c2:17
Compaq Computer Corporation
192.168.1.13
00:02:b3:91:4e:74
Intel Corporation
192.168.1.14
00:02:a5:a9:27:29
Compaq Computer Corporation
192.168.1.17
00:12:3f:ae:c1:df
192.168.1.19
00:90:27:43:c0:57
INTEL CORPORATION
192.168.1.24
00:12:3f:d4:3c:06
192.168.1.29
00:08:74:c0:89:1d
Dell Computer Corp.
192.168.1.34
00:08:74:c0:40:ce
Dell Computer Corp.
192.168.1.36
00:0c:29:d0:a2:18
VMware, Inc.
192.168.1.44
00:18:8b:7a:fe:10
192.168.1.47
00:12:3f:d4:41:86
192.168.1.105
00:13:72:09:ad:76
192.168.1.148
00:90:27:9d:2a:0b
INTEL CORPORATION
192.168.1.155
00:10:db:74:d0:52
Juniper Networks, Inc.
192.168.1.189
00:14:38:93:93:7e
Hewlett Packard
192.168.1.191
00:01:e6:57:8b:68
Hewlett-Packard Company
192.168.1.195
00:10:83:f2:83:76
HEWLETT-PACKARD COMPANY
192.168.1.196
00:30:c1:ae:31:5c
HEWLETT-PACKARD
192.168.1.204
00:11:43:0f:f2:dd
192.168.1.202
00:d0:b7:25:61:6c
INTEL CORPORATION
192.168.1.222
00:90:27:9d:48:90
INTEL CORPORATION
192.168.1.192
00:01:e6:27:27:6e
Hewlett-Packard Company
192.168.1.234
00:c0:9f:0d:00:9a
QUANTA COMPUTER, INC.
192.168.1.251
00:04:27:6a:5d:a1
Cisco Systems, Inc.
192.168.1.250
00:06:d7:55:0f:40
Cisco Systems, Inc.
34 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.5.2: 256 hosts scanned in 1.717 seconds (149.10 hosts/sec).
33 responded
Here arp-scan scans the 192.168.1.0/24 network attached to eth0.
It sends an ARP request for each IP address in the attached network (including the network and broadcast addresses) and for each host that responds, it displays the host's IP address, MAC address and the vendor string corresponding to the MAC address (this is generally determined by the first three bytes of the MAC address).
Any hosts that respond to the ARP request are displayed in the format:
&IP Address&
&Hardware Address&
&Vendor Details&
The IP address, Hardware address and vendor details are each separated by a single TAB character.
There is always a single blank line between the last responding system and the statistics display.
arp-scan will never report the scanning host's own IP address, because the testing system won't respond to its own ARP request.
This is generally the desired behaviour, as we are almost never interested in the details of the testing system.
Although arp-scan reports the datalink type as EN10MB, this does not necessarily mean that it is 10Mbit E it could by any type (10Mbit, 100Mbit, 1Gbit or 802.11a/b/g).
EN10MB is the name used by libpcap for all types of Ethernet.
It is possible to specify a list of IP addresses to send ARP requests for instead of using --localnet to specify all the addresses within the attached network.
There are five ways to specify the list of target addresses:
Specify a list of IP addresses as arguments, e.g. arp-scan --interface=eth0 192.168.1.1 192.168.1.2 192.168.1.3
Specify the network in &network&/&bits& format, e.g. arp-scan --interface=eth0 192.168.1.0/24
Specify the network in &network&:&netmask& format, e.g. arp-scan --interface=eth0 192.168.1.0:255.255.255.0
Specify the inclusive address range in &start&-&end& format, e.g. arp-scan --interface=eth0 192.168.1.3-192.168.1.27
Read the list of IP addresses from a file, e.g. arp-scan --interface=eth0 --file=ip-address-list.txt
For the network specifications, &network&/&bits& and &network&:&netmask&, the resulting list of IP addresses includes the network and broadcast addresses.
When reading the IP addresses from a file, the file should contain one IP address per line.
It is possible to use hostnames instead of IP addresses, e.g. arp-scan --interface=eth0 orion.
This will lookup the IP address for orion with gethostbyname().
It is possible to disable this, so that all arguments must be IP addresses, with the --numeric option.
In this case, the inet_pton() function is used to convert the IP address string.
The --numeric option is useful when DNS is not working, where it can avoid long delays caused by failed DNS lookups.
If you find that arp-scan is taking a long time to run, this is one of the first things to try.
Don't forget that the ARP protocol only works on the local Ethernet segment, and cannot be routed. So you cannot use arp-scan to discover hosts behind routers with the exception of remote interfaces on some multi-homed systems, and proxy-arp responses from routers.
Here is an example showing arp-scan being run against the eight addresses in the network 192.168.1.0/29:
$ arp-scan --interface=eth0 192.168.1.0/29
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.5.2 with 8 hosts (http://www./tools/arp-scan/)
192.168.1.1
00:c0:9f:09:b8:db
QUANTA COMPUTER, INC.
192.168.1.3
00:02:b3:bb:66:98
Intel Corporation
192.168.1.4
00:02:b3:bb:5c:09
Intel Corporation
192.168.1.5
00:02:a5:90:c3:e6
Compaq Computer Corporation
192.168.1.6
00:c0:9f:0b:91:d1
QUANTA COMPUTER, INC.
6 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.5.2: 8 hosts scanned in 0.885 seconds (9.04 hosts/sec).
5 responded
You can still use arp-scan even if the interface does not have an IP address.
If you use arp-scan in this way, it will use the IP address of 0.0.0.0 for the ar$sha field in the ARP packet unless you specify the IP address to use with the -arpsha option.
Some operating systems will only respond to ARP requests if the IP address specified in the ar$sha field is plausible.
The exact rules vary between operating systems, but the most common is that the address in ar$sha must be within the IP network of the interface that the ARP request is received on.
This is explored further in the fingerprinting section.
The list of target hosts is stored in memory.
Each host in this list uses 28 bytes of memory, so scanning a Class-B network
hosts) requires
of memory for the list, and scanning a Class-A (16,777,216 hosts) requires about 448MB.
Each host entry is described by the following C structure:
typedef struct {
/* Timeout for this host in us */
struct in_
/* Host IP address */
struct timeval last_send_ /* Time when last packet sent to this addr */
unsigned short num_
/* Number of packets sent */
unsigned short num_
/* Number of packets received */
/* Set when awaiting response */
One ARP packet is sent for each for each target host, with
target protocol address (the ar$tpa field) set to the IP address of this host. If a host does not respond, then the ARP packet will
once more.
number of retries can be changed with the --retry option.
Reducing the number of retries will reduce the
time at the possible risk of missing some results due to packet loss.
specify the bandwidth that arp-scan will use for the outgoing ARP packets with the --bandwidth option.
By default, it uses
256000 bits per second. Increasing the bandwidth will reduce the scanning time, but setting the bandwidth too high may result in
an ARP storm which can disrupt network operation.
Also, setting the bandwidth too high can send packets faster than the network
can transmit
them, which will eventually fill the kernel's transmit buffer resulting in the error message: No buffer space available.
Another way to
specify the outgoing ARP packet rate is with the --interval option, which is an alternative way to modify the same underlying parameter.
The time in seconds to perform a single-pass scan (i.e. with --retry=1)
is given by:
time = n*i + t + o
of hosts in the list, i is the time interval between packets (specified with --interval, or calculated from
--bandwidth),
t is the timeout value (specified with --timeout) and o is the overhead time taken to load the targets into
the MAC/Vendor
mapping files.
For small lists of hosts, the timeout value will dominate, but for large lists the
most important value.
65,536 hosts, the default bandwidth of 256,000 bits/second (which results in a packet interval of 2ms), the default timeout of 100ms, and a
pass (--retry=1), and assuming an overhead of 1 second, the scan would take
+ 0.1 + 1 = 132.172
2 minutes 12 seconds.
In addition to system discovery, you can also use arp-scan to perform various types of system fingerprinting as detailed below.
This is particually useful on Firewalls and systems employing IP ingress filtering that do not have any accessible IP network services.
Unless the --quiet option is specified, arp-scan decodes the vendor details from the MAC address and displays these details in the third column, after the MAC address.
Below is an example using a Cisco router where the vendor details are Cisco Systems, Inc.
192.168.1.251
00:04:27:6a:5d:a1
Cisco Systems, Inc.
arp-scan uses data from three files to decode the vendor details:
ieee-oui.txt - This the IEEE OUI (Organizationally Unique Identifier) list, which is obtained from the IEEE website and can be updated with the get-oui script that is included with arp-scan.
ieee-iab.txt - This the IEEE IAB (Individual Address Block) list, which is obtained from the IEEE website and can be updated with the get-iab script that is included with arp-scan.
mac-vendor.txt - This is a list of other MAC address / vendor mappings.
This list is manually maintained, and is much smaller than the OUI and IAB listings.
When arp-scan starts up it reads the contents of all three files into a hash table, and it matches the MAC addresses of any ARP replies that it receives against this hash table to decode the vendor string.
The vendor details can often help to identify the device type.
In the example above, the vendor string Cisco Systems, Inc. suggests that the device is a Cisco.
The vendor details depend on the manufacturer of the network interface, which may well be different from the manufacturer of the entire system, e.g. a 3COM Ethernet card in an HP server.
Different IP stack implementations respond differently to non-standard ARP packets.
arp-scan includes the arp-fingerprint tool that uses these differences to fingerprint the implementation. arp-fingerprint is a Perl script, which uses arp-scan to send and receive the ARP packets. The table below shows the tests that arp-fingerprint performs:
No.Descriptionarp-scan optionNotes
1source protocol address = localhost--arpspa=127.0.0.1IP address 127.0.0.1 should never appear as a source address on the LAN
2source protocol address = zero--arpspa=0.0.0.0
3source protocol address = broadcast--arpspa=255.255.255.255
4source protocol address = non-local--arpspa=1.0.0.1IP network 1.0.0.0/8 is reserved by IANA, so should never belong on the target's local LAN
5Invalid Opcode--arpop=255Opcode 255 is not defined
6Hardware Type = IEEE_802.2--arphrd=6Most systems respond to this as well as the default hardware type 1
7Invalid hardware type--arphrd=255
8Invalid protocol type--arppro=0xffff
9Protocol type = IPX--arppro=0x8137
10Invalid protocol address length--arppln=6The protocol address length is normally four bytes
11Invalid hardware address length--arphln=8The hardware address length is normally six bytes
Each of these tests results in a yes/no answer depending on whether the target host responded or not.
arp-fingerprint constructs a string of binary digits from the responses to the tests, with a response being encoded as "1" and no response being "0", and uses the resultant binary string to match against a list of known fingerprints.
Below are some examples of arp-fingerprint being used against some different targets.
arp-fingerprint displays the IP address, the binary fingerprint string, and a list of known systems that match this fingerprint:
$ arp-fingerprint -o &--interface=eth0 --numeric& 192.168.1.1
192.168.1.1
Linux 2.2, 2.4, 2.6
$ arp-fingerprint -o &--interface=eth0 --numeric& 192.168.1.204
192.168.1.204
FreeBSD 5.3, Win98, WinME, NT4, 2000, XP, 2003
$ arp-fingerprint -o &--interface=eth0 --numeric& 192.168.1.251
192.168.1.251
Cisco IOS 11.2, 11.3, 12.0, 12.1, 12.2, 12.3, 12.4
$ arp-fingerprint -o &--interface=eth0 --numeric& 192.168.1.155
192.168.1.155
ScreenOS 5.0, 5.1, 5.3, 5.4
In each of the examples above we use arp-fingerprint's -o option to pass the --interface=eth0 --numeric option string to arp-scan.
The -o option can be used to pass any options to arp-scan, with the two most common ones being --interface to specify the network interface and --numeric to avoid DNS lookups.
Many of the fingerprint strings are shared by
there is not always a one-to-one mapping between fingerprint strings and operating systems. Also the fact that
fingerprint matches a certain operating system (or list of operating systems) does not necessarily mean that the system being fingerprinted
that operating system, although it is quite likely. This is because the list of operating syste it is just what I have
discovered
to date, and there are bound to be operating systems that are not listed.
Sometimes, an operating system can give different fingerprints
depending on the configuration.
An example is Linux, which will respond to a non-local source IP address if that IP is routed through the
interface being tested.
This is both good and bad: on one hand it makes the fingerprinti but on the
some aspects of the system configuration to be determined.
Sometimes the fact that two different operating systems share a common ARP fingerprint string points to a re-use of networking code. One example of this is Windows NT and FreeBSD.
If you find a system that arp-fingerprint reports as UNKNOWN,
you know what operating system it is running, please send details of the operating system and fingerprint to
include it in future versions. Please include the exact version of the operating system if
fingerprints
sometimes change between versions.
arp-scan sends the ARP requests to the Ethernet broadcast address ff:ff:ff:ff:ff:ff by default, but this can be changed with the --destaddr option.
An interface that is not in promiscuous mode will pass Ethernet packets to the operating system if the destination address is one of:
The Ethernet broadcast address ff:ff:ff:ff:ff:
The interface' or
An Ethernet multicast address that the system is listening on.
You can always use the target system's MAC address as the target if you know it.
This can be useful to check that a given system with known IP and MAC addresses is present on the LAN, and it has the advantage that it is quieter than using the broadcast because it won't be received by all network stations.
Below is an example of using a host's unicast MAC address.
In this example, we first use arp-scan with the default broadcast destination to determine the host's MAC address, and then run arp-scan again specifying the host's MAC address as the detination.
$ arp-scan --interface=eth0 192.168.1.1
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.5.2 with 1 hosts (http://www./tools/arp-scan/)
192.168.1.1
00:c0:9f:09:b8:db
QUANTA COMPUTER, INC.
$ arp-scan --interface=eth0 --destaddr=00:c0:9f:09:b8:db 192.168.1.1
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.5.2 with 1 hosts (http://www./tools/arp-scan/)
192.168.1.1
00:c0:9f:09:b8:db
QUANTA COMPUTER, INC.
If you send the ARP requests to an Ethernet multicast address it will only be received by those systems that are listening on that multicast address, or have set their Ethernet interface into promiscuous mode (and therefore receive all packets).
This can be used to find systems that are running in promiscuous mode, or listen on particular multicast addresses.
The table below shows some common Ethernet multicast addresses:
Multicast AddressDescription
01:00:0c:cc:cc:ccCDP (Cisco Discovery Protocol)
01:00:0c:cc:cc:cdSSTP (Shared Spanning Tree Protocol)
01:80:c2:00:00:00Spanning Tree
01:00:5e:00:00:05OSPF
01:00:5e:00:00:12VRRP
03:00:c7:00:00:eeHP network teaming
This example shows the use of the --destaddr option with the OSPF multicast address to detect systems listing to OSPF multicasts.
First we scan three systems using the default options.
The IP addresses are 192.168.1.1, 192.168.1.204 and 192.168.1.254, which are running Linux 2.6.19, Windows 2003 and Cisco IOS 12.2(29) respectively.
All three systems respond as expected.
$ arp-scan --interface=eth0 192.168.1.1 192.168.1.204 192.168.1.254
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.6.2 with 3 hosts (http://www./tools/arp-scan/)
192.168.1.1
00:c0:9f:09:b8:db
QUANTA COMPUTER, INC.
192.168.1.204 00:11:43:0f:f2:dd
192.168.1.254 00:60:5c:f4:c6:f4
CISCO SYSTEMS, INC.
Next we scan the same systems, but specify --destaddr=01:00:5e:00:00:05 to set the Ethernet destination address to the OSPF multicast address.
Only the Cisco router responds, because that is the only system that is listening to the OSPF multicast address.
$ arp-scan --interface=eth0 --destaddr=01:00:5e:00:00:05 192.168.1.1 192.168.1.204 192.168.1.254
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.6.2 with 3 hosts (http://www./tools/arp-scan/)
192.168.1.254 00:60:5c:f4:c6:f4
CISCO SYSTEMS, INC.
First we scan three systems using the default options.
The IP addresses are 192.168.1.1, 192.168.1.204 and 192.168.1.254, which are running Linux 2.6.19, Windows 2003 and Cisco IOS 12.2(29) respectively.
All three systems respond as expected.
$ arp-scan --interface=eth0 192.168.1.1 192.168.1.204 192.168.1.254
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.6.2 with 3 hosts (http://www./tools/arp-scan/)
192.168.1.1
00:c0:9f:09:b8:db
QUANTA COMPUTER, INC.
192.168.1.204 00:11:43:0f:f2:dd
192.168.1.254 00:60:5c:f4:c6:f4
CISCO SYSTEMS, INC.
Next we scan the same systems, but specify --destaddr=01:00:01:02:03:04 to set the Ethernet destination address to an unassigned multicast address.
Only the Linux system responds, because it is running tcpdump which has put its Ethernet interface into promiscuous mode.
$ arp-scan --interface=eth0 --destaddr=01:00:01:02:03:04 192.168.1.1 192.168.1.204 192.168.1.254
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.6.2 with 3 hosts (http://www./tools/arp-scan/)
192.168.1.1
00:c0:9f:09:b8:db
QUANTA COMPUTER, INC.
ARP packets are only 28 bytes long, which is shorter than the minimum Ethernet frame length of 46 bytes. Therefore each ARP packet must be followed by at least 18 bytes of padding. If the ARP implementation doesn't pad the outgoing ARP frames, then the Ethernet driver must do so.
The diagram below shows an ARP packet within an Ethernet frame with padding to achieve the minimum Ethernet frame size.
ARP packet showing Ethernet frame padding
arp-scan can add arbitary padding data to the outgoing ARP requests with the --padding option.
If the --verbose option is specified, then arp-scan will report any non-zero padding on received ARP responses.
Most implementations will pad up to the minimum frame length with zero bytes, but not all implementations do this.
Below are some examples of systems that return non-zero padding bytes:
$ arp-scan --interface=eth0 --padding=0708 --verbose 192.168.1.0/24 | grep Padding
192.168.1.147
00:11:24:84:a1:b2
Apple Computer
192.168.1.153
00:10:db:26:4d:52
Juniper Networks, Inc.
192.168.1.158
08:00:20:a0:09:a4
SUN MICROSYSTEMS INC.
192.168.1.190
00:00:aa:84:eb:0c
XEROX CORPORATION
192.168.1.192
00:30:c1:cd:3a:13
HEWLETT-PACKARD
192.168.1.249
00:90:27:57:c1:f3
INTEL CORPORATION
Padding=ba2
192.168.1.250
00:06:d7:55:0f:40
Cisco Systems, Inc.
In the example above, the systems are:
IP AddressOperating SystemNotes
192.168.1.147MacOS 10.4pads with 18 bytes of 0x55 (binary )
192.168.1.153NetScreen ScreenOS 5.0.0pads with 18 bytes of 0x88 (binary )
192.168.1.158Solaris 8/SPARC, qfe Ethernetpads with 18 bytes of 0x55 (binary )
192.168.1.190Xerox Phaser 6200re-uses the padding from the ARP request frame
192.168.1.192HP JetDirectre-uses the padding from the ARP request frame
192.168.1.249Linux with eepro100 driveradds four non-zero bytes at the end of the padding
192.168.1.250Cisco Catalyst IOS 12.0adds part of the padding from the request frame
I have not performed much investigation on ARP frame padding, and I suspect that there are more oddities waiting to be discovered.
By default, arp-scan sends ARP requests using Ethernet-II Ethernet framing, which is the standard Ethernet framing for TCP/IP.
If the --llc (-L) option is specified, then arp-scan will send ARP requests using IEEE 802.2 LLC/SNAP Framing instead, as defined in
"Standard for the transmission of IP datagrams over IEEE 802 networks".
ARP Packet with 802.2 LLC/SNAP Framing
Irrespective of whether the --llc option is specified, arp-scan will always receive ARP responses in either Ethernet-II or 802.2 format, and will display "(802.2 LLC/SNAP)" to indicate an 802.2 format ARP response.
The 802.2 LLC/SNAP framing detailed in
is applicable to three underlying physical networks: 802.3 (Ethernet), 802.4 (Token Bus) and 802.5 (Token Ring).
However the current version of arp-scan only supports Ethernet, and cannot be used for 802.4 or 802.5 networks.
The 802.2 LLC framing is obsolete, and is almost never seen on a real world network.
But some network stacks still support it, especially routers, which need to be able to communicate with a diverse range of equipment, and operating systems with a history of use on networks using 802.2 LLC.
The following operating systems have been found to support ARP requests with 802.2 LLC/SNAP framing:
Cisco IOS on routers and Catalyst switches (tested IOS 12.1 and 12.2).
All versions of Windows (tested 95, NT4, 2000, XP, 2003, Vista).
Here is an example from Windows Vista SP1.
Although Windows systems support ARP requests with SNAP framing, they respond with standard Ethernet-II framing.
$ arp-scan --llc 192.168.1.50
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.7 with 1 hosts (http://www./tools/arp-scan/)
192.168.1.50
00:1d:09:94:3e:5f
Here is an example from a Cisco router running IOS 12.2.
Cisco IOS will respond to an ARP request in SNAP format with an ARP reply in SNAP format.
$ arp-scan --llc 192.168.124.251
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.7.1 with 1 hosts (http://www./tools/arp-scan/)
192.168.124.251 00:04:27:6a:5d:a1
Cisco Systems, Inc. (802.2 LLC/SNAP)
If two or more IP addresses respond with the same MAC address then, assuming it's not proxy ARP or an interface on a different network segment, this indicates that the IP addresses are on the same network interface.
Here is an example from a Linux system:
$ arp-scan --interface=eth0 192.168.1.68 192.168.1.69
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.5.2 with 2 hosts (http://www./tools/arp-scan/)
192.168.1.68
00:0b:db:1c:59:e7
Dell ESG PCBA Test
192.168.1.69
00:0b:db:1c:59:e7
Dell ESG PCBA Test
And here is the interface configuration from the system that produced this output:
Link encap:Ethernet
HWaddr 00:0B:DB:1C:59:E7
inet addr:192.168.1.68
Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST
RX packets:14874 errors:0 dropped:0 overruns:0 frame:0
TX packets:4822 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:.2 MiB)
TX bytes:2.8 KiB)
Interrupt:7
Link encap:Ethernet
HWaddr 00:0B:DB:1C:59:E7
inet addr:192.168.1.69
Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST
Interrupt:7
Systems with multiple interfaces often (but not always) have MAC addresses that are very close together.
This is because the interface cards in a batch typically have sequential addresses.
When a system is built, the interface cards are typically all sourced from the same batch.
Also, multi-port network cards invariably have sequential MAC addresses for the individual ports.
Here is an example taken from the arp-scan output from six different scans on different Ethernet network segments:
192.168.4.94
00:a0:8e:33:81:f0
Nokia Internet Communications
00:a0:8e:33:81:f1
Nokia Internet Communications
192.168.4.30
00:a0:8e:33:81:f8
Nokia Internet Communications
192.168.5.30
00:a0:8e:33:81:fc
Nokia Internet Communications
192.168.5.45
00:a0:8e:33:81:fd
Nokia Internet Communications
192.168.5.145
00:a0:8e:33:81:ff
Nokia Internet Communications
We can see that all six of the MAC addresses are very close together.
They all belong to a single Nokia firewall, which connects the six networks.
Many routers will issue
replies for addresses that belong on a different interface. Cisco routers do this by default.
Here is an example of proxy ARP responses from a Cisco router.
In this example, the network 172.18.0.0/28 is on a different Ethernet interface from the testing system.
$ arp-scan --interface=eth0 172.18.0.0/28
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.5.2 with 16 hosts (http://www./tools/arp-scan/)
172.18.0.0
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.1
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.2
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.3
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.4
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.5
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.6
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.7
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.8
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.9
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.10
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.11
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.12
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.13
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.14
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.15
00:04:27:6a:5d:a1
Cisco Systems, Inc.
18 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.5.2: 16 hosts scanned in 0.655 seconds (24.43 hosts/sec).
16 responded
It's normally fairly easy to spot proxy ARP replies because:
You get responses for all addresses in the IP network
All responses use the same Ethernet MAC address
The MAC address belongs to a router device
Because proxy ARP is enabled by default on some routers, you can use arp-scan to determine the IP networks behind these routers.
This can be a useful network mapping technique, especially when the router blocks ping and traceroute traffic.
Load balancing and failover protocols including
(Virtual Router Redundancy Protocol),
(Hot Standby Routing Protocol) and
(Windows NT Load Balancing Service) encode additional data within the MAC address.
There are probably other protocols that do the same thing.
Here are the entries for these protocols from mac-vendor.txt:
# From RFC -5E-00-01-{VRID}
VRRP (last octet is VRID)
# Microsoft WLBS (Windows NT Load Balancing Service)
# /technet/prodtechnol/acs/reskit/acrkappb.mspx
Microsoft WLBS (last four octets are IP address)
# Cisco HSRP (Hot Standby Routing Protocol)
# 00-00-0c-07-ac-XX
00000C07AC
HSRP (last octet is group number)
When arp-scan displays MAC addresses associated with these protocols, you can determine additional information from the MAC address.
For VRRP you can determine the VRID (Virtual Router IDentifier) from the last octet, and for WLBS you can determine the IP address from the last four octets.
Here are some examples of arp-scan output for VRRP IP addresses:
192.168.6.20
00:00:5e:00:01:65
VRRP (last octet is VRID)
192.168.6.227
00:00:5e:00:01:72
VRRP (last octet is VRID)
192.168.6.228
00:00:5e:00:01:40
VRRP (last octet is VRID)
In this example, the first IP address belongs to VRID 101 (0x65), the second to VRID 114 (0x72) and the last to VRID 64 (0x40).
If anyone is aware of any other protocols that store additional information in the MAC address, please let me know so that I can include them in mac-vendor.txt.
Linux, like many other operating systems, will only respond to an ARP request if the IP address in ar$spa is within the IP network of the interface that the ARP is received on.
However, Linux also replies if the IP address in ar$spa is routed through the interface that the ARP request is received on.
This allows you to determine the IP networks that are routed via a given interface on Linux, and any other operating systems that behave in the same way.
arp-scan works on 802.11 wireless (wifi) networks in exactly the same way as it does on conventional Ethernet networks, because wireless networks use the same Ethernet data-link protocol as normal Ethernet.
The reason wireless is specifically mentioned is because not everyone realises that arp-scan works on wireless networks.
The main differences when running arp-scan on wireless networks are:
You need to associate with the network before you can start scanning.
Wireless networks use MAC address filtering much more than wired networks do, so you might find that your MAC address is blocked.
arp-scan lets you change the source MAC address in the Ethernet header with the --srcaddr option, and this is sometimes useful in these situations.
Hosts on wireless networks are more transient than those on wired networks, so it's often worth scanning a few times with a time gap between scans.
Below is an example of arp-scan being used on an 802.11g wireless network.
In this example we are scanning from a Linux laptop with a Proxim 802.11g card that is associated with a Linksys WRT54G access point.
$ iwconfig ath0
IEEE 802.11g
ESSID:&what ever i want&
Nickname:&&
Mode:Managed
Frequency:2.437 GHz
Access Point: 00:12:17:C7:E0:E2
Bit Rate:48 Mb/s
Tx-Power:31 dBm
Sensitivity=0/3
RTS thr:off
Fragment thr:off
Power Management:off
Link Quality=61/94
Signal level=-37 dBm
Noise level=-98 dBm
Rx invalid nwid:370
Rx invalid crypt:0
Rx invalid frag:0
Tx excessive retries:0
Invalid misc:0
Missed beacon:0
$ ifconfig ath0
Link encap:Ethernet
HWaddr 00:20:A6:51:5E:51
inet addr:192.168.1.101
Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST
RX packets:9326 errors:0 dropped:0 overruns:0 frame:0
TX packets:10425 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:.2 MiB)
TX bytes:5.5 KiB)
$ arp-scan --interface=ath0 --localnet
Interface: ath0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.5.2 with 256 hosts (http://www./tools/arp-scan/)
192.168.1.1
00:12:17:c7:e0:e0
Cisco-Linksys, LLC
192.168.1.102
00:13:02:34:26:c7
Intel Corporate
We can see that there are two hosts on the wireless network: the access point at IP address 192.168.1.1, and another laptop at 192.168.1.102.
Note that the discovered MAC address for the access point is not the same as the access point MAC address reported by iwconfig, although they are so close that they obviously belong to the same device.
I suspect that the wireless ethernet interface on this AP does not actually have an IP address, but is bridged to the LAN interface which does.
Some systems only answer ARP requests where the address in ar$spa is within the IP network of the interface that the request is received on.
You can use this behaviour to determine the interface netmask on these systems as follows:
First discover the system's IP address - this gives you an address that is within the system'
Next use the
to locate the lowest address in the interface network. For this search, use zero as the lower bound, and the interface IP
Finally use the binary search algorithm to locate the highest address, using the interface IP as the lower bound and 255.255.255.255 (0xFFFFFFFF or 4,294,967,295) as the upper bound.
An alternative method is to test network address bounds based on likely netmasks rather than using the general binary search technique.
Below is an example using a Cisco router as the target.
In this example, the configuration of the router's Ethernet interface is:
interface Ethernet0
ip address 192.168.1.254 255.255.255.240
The arp-scan runs below show that the router will only respond when the address in the ar$spa field is within the connected IP network of the interface, including the network and broadcast addresses.
In this example the IP network is 192.168.1.240/28, so the IP addresses within the network are 192.168.1.240 - 192.168.1.255 inclusive.
$ arp-scan --interface=eth0 --arpspa=192.168.1.239 192.168.1.254
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.5.2 with 1 hosts (http://www./tools/arp-scan/)
2 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.5.2: 1 hosts scanned in 0.865 seconds (1.16 hosts/sec).
0 responded
$ arp-scan --interface=eth0 --arpspa=192.168.1.240 192.168.1.254
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.5.2 with 1 hosts (http://www./tools/arp-scan/)
192.168.1.254
00:60:5c:f4:c6:f4
CISCO SYSTEMS, INC.
3 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.5.2: 1 hosts scanned in 0.618 seconds (1.62 hosts/sec).
1 responded
$ arp-scan --interface=eth0 --arpspa=192.168.1.255 192.168.1.254
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.5.2 with 1 hosts (http://www./tools/arp-scan/)
192.168.1.254
00:60:5c:f4:c6:f4
CISCO SYSTEMS, INC.
3 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.5.2: 1 hosts scanned in 0.608 seconds (1.64 hosts/sec).
1 responded
$ arp-scan --interface=eth0 --arpspa=192.168.2.0 192.168.1.254
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.5.2 with 1 hosts (http://www./tools/arp-scan/)
2 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.5.2: 1 hosts scanned in 0.863 seconds (1.16 hosts/sec).
0 responded
Some systems will respond to ARP requests for any interface, not only the interface that the request was received on.
For these systems we can use arp-scan to discover the IP addresses of any other interfaces they may have.
The ARP response from such systems will always use the MAC address of the local interface, not the remote one.
This is a type of
that allows a host to reach any of the interface addresses of systems connected
to the same network without requiring an IP route entry.
The example below shows the response from a Linux system with two ethernet interfaces:
$ arp-scan --interface=eth0 192.168.1.1 10.0.105.225
192.168.1.1
00:c0:9f:09:b8:db
QUANTA COMPUTER, INC.
10.0.105.225
00:c0:9f:09:b8:db
QUANTA COMPUTER, INC.
Link encap:Ethernet
HWaddr 00:C0:9F:09:B8:DB
inet addr:192.168.1.1
Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST
RX packets:5286713 errors:0 dropped:0 overruns:0 frame:0
TX packets: errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes: (1.0 GiB)
TX bytes: (3.9 GiB)
Link encap:Ethernet
HWaddr 00:D0:B7:40:D1:61
inet addr:10.0.105.225
Bcast:10.0.105.255
Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST
RX packets:2673325 errors:0 dropped:0 overruns:0 frame:0
TX packets:2409354 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes: (2.0 GiB)
TX bytes: (398.3 MiB)
Here is another example, this time from a Cisco router that is using 802.1Q VLAN sub-interfaces:
$ arp-scan --interface=eth0 192.168.1.251 172.18.0.1 172.18.2.1
192.168.1.251
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.0.1
00:04:27:6a:5d:a1
Cisco Systems, Inc.
172.18.2.1
00:04:27:6a:5d:a1
Cisco Systems, Inc.
interface FastEthernet0/1.50
encapsulation dot1Q 50
ip address 172.18.0.1 255.255.255.0
interface FastEthernet0/1.100
encapsulation dot1Q 100
ip address 192.168.1.251 255.255.255.0
interface FastEthernet0/1.300
encapsulation dot1Q 300
ip address 172.18.2.1 255.255.255.0
Here is a negative example from a Solaris 9 system that does not exhibit this behaviour.
In this case, the system only responds to the request for the local interface IP:
$ arp-scan --interface=eth0 192.168.1.150 10.0.0.1
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.2 (ether-scan-engine 1.3) with 2 hosts
192.168.1.150
08:00:20:a0:09:a4
SUN MICROSYSTEMS INC.
3 packets received by filter, 0 packets dropped by kernel
Ending arp-scan: 2 hosts scanned in 0.749 seconds (2.67 hosts/sec).
1 responded
qfe0: flags=1000843&UP,BROADCAST,RUNNING,MULTICAST,IPv4& mtu 1500 index 2
inet 192.168.1.150 netmask ffffff00 broadcast 192.168.1.255
qfe1: flags=1000803&UP,BROADCAST,MULTICAST,IPv4& mtu 1500 index 3
inet 10.0.0.1 netmask ff000000 broadcast 10.255.255.255
So far, I know of the following operating systems that respond to ARP requests for remote interface addresses:
The following operating systems are known not to respond to ARP requests for remote interface addresses:
Windows NT 4
WARNING: Setting ar$spa to the destination IP address can disrupt target system operation
You can use the --arpspa=dest option to set the ar$spa field in the ARP request to the same IP address as the target.
For single targets you could achieve the same effect by specifying the same IP address in the arpspa option and also the target IP address, but --arpspa=dest has the advantage that it works for multiple targets too.
Many systems interpret this as a promiscuous ARP, and assume there must be an IP address clash if they receive an ARP request for their own address.
For this reason you should use --arpspa=dest with care, as it can disrupt some systems.
In some ways this is an ARP version of the 1997-vintage LAND attack.
Here is an example of this against a Windows XP SP2 system.
The windows system responds to the ARP request, but also logs an IP address conflict error.
$ arp-scan --interface=eth0 --arpspa=dest 192.168.124.11
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.5.2 with 1 hosts (http://www./tools/arp-scan/)
192.168.124.11
00:0f:1f:5c:d1:13
WW PCBA Test
If you specify the --verbose option arp-scan will display additional debugging output, which can be useful in some circumstances.
Here is an example:
$ arp-scan --interface=eth0 --verbose 192.168.1.0/29
Interface: eth0, datalink type: EN10MB (Ethernet)
DEBUG: pcap filter string: &arp and ether dst 00:02:b3:bb:5c:11&
DEBUG: Loaded 9978 IEEE OUI/Vendor entries from /usr/local/share/arp-scan/ieee-oui.txt.
DEBUG: Loaded 1781 IEEE IAB/Vendor entries from /usr/local/share/arp-scan/ieee-iab.txt.
DEBUG: Loaded 4 MAC/Vendor entries from /usr/local/share/arp-scan/mac-vendor.txt.
DEBUG: pkt len=64 bytes, bandwidth=256000 bps, interval=2000 us
Starting arp-scan 1.5.2 with 8 hosts (http://www./tools/arp-scan/)
192.168.1.1
00:c0:9f:09:b8:db
QUANTA COMPUTER, INC.
192.168.1.3
00:02:b3:bb:66:98
Intel Corporation
192.168.1.4
00:02:b3:bb:5c:09
Intel Corporation
192.168.1.5
00:02:a5:90:c3:e6
Compaq Computer Corporation
192.168.1.6
00:c0:9f:0b:91:d1
QUANTA COMPUTER, INC.
Pass 1 complete
Pass 2 complete
8 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.5.2: 8 hosts scanned in 0.895 seconds (8.94 hosts/sec).
5 responded
We can see that specifying the --verbose option has added the following additional items of information to the arp-scan output:
The filter string use by libpcap to capture ARP responses: pcap filter string: "arp and ether dst 00:02:b3:bb:5c:11"
The number of vendor string entries loaded from the OUI, IAB and MAC/Vendor files, and the locations of these files.
The packet interval calculation for the desired output bandwidth.
Details of when each pass is complete.
In this example we see that all hosts have responded after the first pass, which is typical behaviour.
Specifying the --vlan (-Q) option causes an 802.1Q header containing the specified VLAN number to be added to the outgoing ARP request frames as shown in the diagram below.
ARP packet with 802.1Q VLAN tag
Irrespective of whether the --vlan option was specified, arp-scan will always receive ARP replies either with or without an 802.1Q header, and will display "(802.1Q VLAN=&n&)" to indicate a response containing a 802.1Q header and show the VLAN number.
If the system running arp-scan is on a switch trunk port, then the --vlan option can be used to scan systems in any VLAN.
If the --pcapsavefile (-W) option is used, then the received ARP replies are written to the specified PCAP savefile in addition to being displayed in the normal way.
This option can be useful if you want to perform additional analysis on the received ARP responses.
Here is an example showing the use of the --pcapsavefile option, and analysis of the PCAP savefile with tcpdump.
$ arp-scan -I eth0 --pcapsavefile=arp-pcap 192.168.124.1
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.7 with 1 hosts (http://www./tools/arp-scan/)
192.168.124.1
00:c0:9f:09:b8:db
QUANTA COMPUTER, INC.
$ tcpdump -n -r arp-pcap
reading from file arp-pcap, link-type EN10MB (Ethernet)
10:53:33.029285 arp reply 192.168.124.1 is-at 00:c0:9f:09:b8:db
Here is a list of strange behaviour that I've noticed while using arp-scan.
Some systems have been observed to send multiple ARP responses to a single ARP request.
arp-scan flags these duplicate responses as DUP: n in the output, where n is the number of times we've seen this reply.
Here is an example from an arp-scan against a Class-C network.
The -N option is the short form of --nodns, which prevents any DNS and -r 1 is the short form for --retry=1, which ensures that only one ARP request is sent.
% arp-scan -N -r 1 -s 192.168.1.40 192.168.1.0/24
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.2 (ether-scan-engine 1.3) with 256 hosts
192.168.1.33
00:00:5e:00:01:ca
USC INFORMATION SCIENCES INST
192.168.1.34
00:0b:46:e4:8d:6d
192.168.1.34
00:0b:46:e4:8d:6d
Cisco (DUP: 2)
192.168.1.45
00:0a:b7:9b:b7:7a
Cisco Systems
192.168.1.46
00:0a:b7:9b:b7:01
Cisco Systems
We see that the Cisco system with IP address 192.168.1.34 and MAC address 00:0b:46:e4:8d:6d responds twice to the single ARP request.
Here is the tcpdump output from another example:
00:0b:db:1c:59:e7 & ff:ff:ff:ff:ff:ff, ethertype ARP, length 42: arp who-has 192.168.1.99 tell 192.168.1.102
04 b db1c 59e7 c0a8
00:e0:b6:06:9d:1d & 00:0b:db:1c:59:e7, ethertype ARP, length 60: arp reply 192.168.1.99 is-at 00:e0:b6:06:9d:1d
b606 9d1d c0a8
b db1c 59e7 c0a8 00
00 00 0000
00:e0:b6:06:9d:1d & 00:0b:db:1c:59:e7, ethertype ARP, length 60: arp reply 192.168.1.99 is-at 00:e0:b6:06:9d:1d
b606 9d1d c0a8
b db1c 59e7 c0a8 00
00 00 0000
Here the ARP request is sent, and the first reply comes back in 252us followed by a second reply 262us after the first. The vendor OUI for this device is "Entrada Networks".
I do not know what causes this behaviour, and suspect that it is a bug in the IP stack.
If anyone knows the cause, please let me know.
The data used to decode the vendor string from the Ethernet MAC address is kept in three files:
ieee-oui.txt - IEEE OUI data
ieee-iab.txt - IEEE IAB data
mac-vendor.txt - Manual ARP/Vendor mappings
The first two of these are generated from the data on the IEEE the last one is manually maintained by the arp-scan author.
Each new release of arp-scan will contain updated versions of all three files.
However you can also update them yourself between releases, and it is suggested that you update from time to time to ensure that the data is up to date.
You can update the first two files using the Perl scripts get-oui and get-iab, which are included in the arp-scan distribution.
To use these scripts, first change directory to the place where these files are stored.
The exact location depends on what was selected when arp-scan was configured, but it is generally /usr/local/share/arp-scan or /usr/share/arp-scan.
Ensure that you have write access in this directory (which normally means that you'll need to be root).
Then run the two scripts.
If you specify the -v (verbose) option, then they will display progress messages.
The scripts will rename any existing ieee-oui.txt or ieee-iab.txt files to .bak.
Below is an example of these scripts being run.
$ get-oui -v
Renaming ieee-oui.txt to ieee-oui.txt.bak
Fetching OUI data from http://standards.ieee.org/regauth/oui/oui.txt
Fetched 1612386 bytes
Opening output file ieee-oui.txt
10164 OUI entries written to file ieee-oui.txt
$ get-iab -v
Renaming ieee-iab.txt to ieee-iab.txt.bak
Fetching IAB data from http://standards.ieee.org/regauth/oui/iab.txt
Fetched 277016 bytes
Opening output file ieee-iab.txt
1843 IAB entries written to file ieee-iab.txt
The latest mac-vendor.txt is available from the .
This is a small text file, and it is updated less frequently than the IEEE-maintained files.
You can cut and paste this file over your version if it is updated.
Personal tools
This page was last modified on 4 February 2011, at 13:02.
This page has been accessed 459,905 times.