We help IT Professionals succeed at work.

How to discover MAC if I have an IP address

DrDamnit asked
Last Modified: 2013-12-16
I have the IP address of a device in the network, and I need to know the MAC of that device.

How do I find out the MAC address of the device sitting at that IP address on the network?

PS: the ip address is on a different / routed subnet. I can ping just fine, but arp shows nothing.
Watch Question

you could check DHCP i think the mac addresses are  listed there
Most Valuable Expert 2012


this isn't the DHCP server.
Most Valuable Expert 2012


and...I don't have access to that DHCP server. Just this one box.
Kent OlsenData Warehouse / Database Architect

Hi DrDamnit,

What O/S are you using?

Use ifconfig to show device ips and mac addresses.
Kent OlsenData Warehouse / Database Architect

Hi DrDamnit,

I suspect that you're in a Micro$oft environment.  If so,use getmac.

From a command prompt, type

  getmac /h

You'll probably want to include the /S /U /V flats

Good Luck,
Most Valuable Expert 2012


To clarify:

I am in a mixed environment. THe only box I have access to is a Linux box (running rPath). I am trying to get the MAC address of a remote device on the network for which I have an IP address.
Unlock this solution and get a sample of our free trial.
(No credit card required)
Kent OlsenData Warehouse / Database Architect

Hi DrDamnit,

MAC addresses don't route.  They are confined to the local network and are the method by which adjacent (switch/hub connected) devices identify each other.  The MAC address means nothing to a device on the other side of the router because the devices don't physically talk to each other -- they talk to the router that's in between them.  They logically talk to each other, but that's different.

getmac is a Windows tool that works under the NetBios protocol.  Obviously, it won't work under linux.  (I don't know what I was thinking earlier....)

arp is the right way, but again, the MAC will be only be in the "local" tables for that subnet.

Good Luck,
Here is no doubt more information than you may require about ARP:

IP to MAC address mappings
Applications use IP addresses and hostnames to identify remote nodes, but packets sent on the Ethernet identify their destinations via a 48-bit MAC-layer address. The Ethernet interface on each host only receives packets that have its MAC address of a broadcast address in the destination field. IP addresses are completely independent of the 48-bit MAC-level address; several disjoint networks may use the same sets of IP addresses although the 48-bit addresses to which they map are unique worldwide.

You can tell who makes an Ethernet interface by looking at the first three octets of its address. Some of the most popular prefixes are shown in Table 13-6. Fortunately, newer diagnostic tools such as ethereal know how to map the prefix number to the vendor of the interface. ethereal is introduced later in this chapter in Section 13.5.2, "ethereal / tethereal".

ARP, the Address Resolution Protocol, is used to maintain tables of 32- to 48-bit address translations. The ARP table is a dynamic collection of MAC-to-IPv4 address mappings. To fill in the MAC-level Ethernet packet headers, the sending host must resolve the destination IPv4 address into a 48-bit address. The host first checks its ARP table for an entry keyed by the IPv4 address, and if none is found, the host broadcasts an ARP request containing the recipient's IPv4 address. Any machine supporting ARP address resolution responds to an ARP request with a packet containing its MAC address. The requester updates its ARP table, fills in the MAC address in the Ethernet packet header, and transmits the packet.
If no reply is received for the ARP request, the transmitting host sends the request again. Typically, a delay of a second or more is inserted between consecutive ARP requests to prevent a series of ARP packets from saturating the network. Flurries of ARP requests sometimes occur when a malformed packet is sent on the network; some hosts interpret it as a broadcast packet and attempt to get the Ethernet address of the sender via an ARP request. If many machines are affected, the ensuing flood of network activity can consume a considerable amount of the available bandwidth. This behavior is referred to as an ARP storm, and is most frequently caused by an electrical problem in a transceiver that damages packets after the host has cleanly written them over its network interface.

To examine the current ARP table entries, use arp -a:

    % arp -a
    Net to Media Table: IPv4
    Device   IP Address               Mask      Flags   Phys Addr
    ------ -------------------- --------------- ----- ---------------
    hme0   caramba           08:00:20:b9:2b:f6
    hme1   socks             08:00:20:e7:91:5d
    hme0   copper            00:20:af:9d:7c:92
    hme0   roger       SP    08:00:20:a0:33:90
    hme0   universo    U    
    hme0   peggy       SP    08:00:20:81:23:f1
    hme1   duke              00:04:00:20:56:d7
    hme0         SM    01:00:5e:00:00:00
    hme1         SM    01:00:5e:00:00:00
    hme1   daisy             08:00:20:b5:3d:d7

The arp -a output listing reports the interface over which the ARP notification arrived, the IP address (or hostname) and its Ethernet address mapping. The unresolved entry (denoted by the U flag) is for a host that did not respond to an ARP request; after several minutes the entry is removed from the table. Complete entries in the ARP table may be static or dynamic, indicating how the address mappings were added and the length of their expected lifetimes.

Solaris identifies static entries with the S flag. The host's own Ethernet address as well as all multicast address entries (identified by the M flag) will always be static.The previous example was run on the host roger, therefore the static nature of the entry for its own Ethernet address and multicast entries. The absence of the S flag identifies a dynamic or learned entry.

Dynamic entries are added on demand during the course of normal IP traffic handling. Infrequently used mappings added in this fashion have a short lifetime; after five minutes without a reference to the entry, the ARP table management routines remove it. This ongoing table pruning is necessary to minimize the overhead of ARP table lookups. The ARP table is accessed using a hash table; a smaller, sparser table has fewer hash key collisions. A host that communicates regularly with many other hosts may have an ARP table that is fairly large, while a host that is quiescent or exchanging packets with only a few peers has a small ARP table.

The difference between dynamic and permanent entries is how they are added to the ARP table. Dynamic entries are added on the fly, as a result of replies to ARP requests. Permanent entries are loaded into the ARP table once at boot time, and are useful if a host must communicate with a node that cannot respond to an ARP request during some part of its startup procedure. For example, a diskless client may not have ARP support embedded in the boot PROM, requiring its boot server to have a permanent ARP table entry for it. Once the diskless node is running the Unix kernel, it should be able to respond to ARP requests to complete dynamic ARP table entries on other hosts.

The arp -a output reports a mask for every entry. This mask is used during lookup of an entry in the ARP table. The lookup function in the kernel applies the mask to the address being queried and compares it with the one in the table. If the resulting addresses match, the lookup is successful. A mask of (all ones) means that the two addresses need to be exactly the same in order to be considered equivalent. A mask of means that only the upper four bits of the address are used to find a matching address. In the previous example, all multicast addresses use the Ethernet address corresponding to the entry. The ARP mask does not provide much useful information to the regular user. Be sure not to confuse this ARP mask with the netmask specified by the ifconfig command. The ARP mask is generated and used only by the internal kernel routines to reduce the number of entries that need to be stored in the table. The netmask specified by the ifconfig command is used for IP routing.

A variation of the permanent ARP table entry is a published mapping. Published mappings are denoted by the P flag. Published entries include the IP address for the current host, and the addresses that have been explicitly added by the -s or -f options (explained later in this chapter).

Publishing ARP table entries turns a host into an ARP server. Normally, a host replies only to requests for its own IP address, but if it has published entries then it replies for multiple IP addresses. If an ARP request is broadcast requesting the IP address of a published entry, the host publishing that entry returns an ARP reply to the sender, even though the IP address in the ARP request does not match its own.

This mechanism is used to cope with machines that cannot respond to ARP requests due to lack of ARP support or because they are isolated from broadcast packets by a piece of network partitioning hardware that filters out broadcast packets. This mechanism is also useful in SLIP or PPP configurations. When any of these situations exist, a machine is designated as an ARP server and is loaded with ARP entries from a file containing hostnames, Ethernet addresses, and the pub qualifier. For example, to publish the ARP entries for hosts relax and stress on server irie, we put the ARP information into a configuration file /etc/arptable and then load it using arp -f:

    irie# cat /etc/arptable
    relax   08:00:20:73:3e:ec         pub
    stress  08:00:20:b9:18:3d  pub
    irie# arp -f /etc/arptable

The -f option forces arp to read the named file for entries, alternatively the -s option can be used to add a single mapping from the command line:

    irie# arp -s relax 08:00:20:73:3e:ec pub

As a diagnostic tool, arp is useful for resolving esoteric point-to-point connectivity problems. If a host's ARP table contains an incorrect entry, the machine using it will not be reachable, since outgoing packets will contain the wrong Ethernet address. ARP table entries may contain incorrect Ethernet addresses for several reasons:

    * Another host on the network is answering ARP requests for the same IP address, or all IP addresses, emulating a duplicate IP address on the network.

    * A host with a published ARP entry contains the wrong Ethernet address in its ARP table.

    * Either of the above situations exist, and the incorrect ARP reply arrives at the requesting host after the correct reply. When ARP table entries are updated dynamically, the last response received is the one that "wins." If the correct ARP response is received from a host that is physically close to the requester, and a duplicate ARP response arrives from a host that is located across several Ethernet bridges, then the later -- and probably incorrect -- response is the one that the machine uses for future packet transmissions.

Inspection of the ARP table can reveal some obvious problems; for example, the three-octet prefix of the machine's Ethernet address does not agree with the vendor's label on the front of the machine. If you believe you are suffering from intermittent ARP failures, you can delete specific ARP table entries and monitor the table as it is repopulated dynamically. ARP table entries are deleted with arp -d, and only the superuser can delete entries. In the following example, we delete the ARP table entry for fenwick, then force the local host to send an ARP request for fenwick by attempting to connect to it using telnet. By examining the ARP table after the connection attempt, we can see if some other host has responded incorrectly to the ARP request:

    # arp -d fenwick
    fenwick ( deleted
    # telnet fenwick
    ...Telnet times out...
    # arp -a | grep fenwick
    hme0   fenwick           08:00:20:79:61:eb
Most Valuable Expert 2012


I figred I was SOL because MACs don't route, but LInux being so uber cool, I still had a glimmer of hope....
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.