Who was that MAC'd man anyway?

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.

Using 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:

cwright@leikata:~>arp 10.1.1.7
Address                  HWtype  HWaddress           Flags Mask            Iface
vaeltaja.softpixel.com   ether   00:11:24:E9:92:AC   C                     eth0

or this on OS X:

cwright@phendrana:~>arp 192.168.255.5
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:

cwright@leikata:~>arp google.com
google.com (64.233.187.99) -- no entry

or this on OS X:

cwright@phendrana:~>arp 35.42.42.42
35.42.42.42 (35.42.42.42) -- 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:

cwright@phendrana:~&gt;arp 192.168.255.11
  192.168.255.11 (192.168.255.11) -- no entry

cwright@phendrana:~&gt;ping 192.168.255.11
  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
  ^C
  --- 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

cwright@phendrana:~&gt;arp 192.168.255.11
  ? (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?

Post new comment