For those that deal with complex networking, having a device’s MAC address can be very helpful in diagnostics, configuration, and firewalling. Often just using a device’s IP address is enough, but what about DHCP? Unless you can control the device’s IP range, this can cause many hours of troubleshooting. This is where having a MAC address helps.
So, how do we get this elusive MAC address anyway? For many devices, it’s printed right on the device. This is by far the easiest and fastest way to get it. But some devices hide this information, and have no interface for figuring it out. For cases like this, we can whip out a handy utility called
arp and some network-jutsu, and purloin these delicious octets with reckless abandon.
arp is a program that manipulates the ARP cache on a system. The ARP cache translates an IP address into a hardware, or MAC, address. So, by pulling data out of this cache, we can find out which MAC address our system uses when we speak to a specific IP address.
arp is very simple for what we’re looking to do.
arp [ip address] will tell us what a given IP or hostname’s MAC address is. This usage looks like this on linux:
Address HWtype HWaddress Flags Mask Iface
vaeltaja.softpixel.com ether 00:11:24:E9:92:AC C eth0
or this on OS X:
server.example.com (192.168.255.5) at 0:30:6e:29:b2:55 on en1 [ethernet]
So far, so good. We can pull data out of the cache, and the MAC address is right there. Is there a catch? Of course there is.
Not having an address in the cache will, of course, make a cache query useless. This is what such a condition looks like on linux:
google.com (18.104.22.168) -- no entry
or this on OS X:
22.214.171.124 (126.96.36.199) -- no entry
No entry!? How can this be? In this example, we’re trying to get the MAC address from an address that isn’t on our local network. Since we only use MAC address for communication on the same LAN, we don’t cache, and thus cannot acquire, MAC addresses from non-local addresses.
Sometimes, however, we’ll receive that error for a machine that is on the network. This happens because we haven’t communicated with the destination machine. To solve this, we simply need to initiate some communication so that we’ll cache the MAC address. I like to use the ping utility, like this:
192.168.255.11 (192.168.255.11) -- no entry
PING 192.168.255.11 (192.168.255.11): 56 data bytes
64 bytes from 192.168.255.11: icmp_seq=0 ttl=30 time=2.612 ms
--- 192.168.255.11 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.612/2.612/2.612/0.000 ms
? (192.168.255.11) at 0:d0:d9:2:f7:6 on en1 [ethernet]
In the first
arp, we have no data in the cache. So, we ping the destination, causing some communication, and thus some cached data. After that, we can query again, and we have our MAC address ready and waiting. That wasn’t so hard, now was it?