Reverse ARP lookup

[Larry Scheetz]

I have an HPUX 11.11 machine and was wondering how I can do a reverse ARP lookup? I have a MAC address and would like to find out the Ip address. Any help would be appreciated. Thx Larry

[Ben Dehner · Accepted solution]

In general, not easily.

Hopefully not to state the obvious, but the target machine must be on the same IP subnet as your HP host. If it is not, then the HP host will never see the MAC address, it will only communicate to the host through a router.

If the system is on the same subnet, and it comunicates with the HP server, you can find the entry in the host's arp cache. Use 'arp -a' and review the list, or use grep or perl or whatever for a string match.

If the system doesn't, as a rule, communicate with your HP server, then you won't find it in the arp cache. (I think arp cache entries are only maintained for a few minutes.) You can force-load the arp cache by running a script that does a 'ping' to every IP address in the subnet, then looking at the arp cache.

Depending on your network infrastructure, looking on the local switches for their forwarding database might be a better way to track down the system. If you have access to those devices.

[rick jones]

i can never remember if going from MAC to IP is reverse ARP or inverse ARP :) anyway, rarp/rarpd, (IIRC) which is not normally found on a UX system (IIRC) would be involved, and that depends on the assistance of the system to which the MAC is assigned.

as already mentioned, you generally need to be on the same subnet (link-layer broadcast domain) to make this work, unless you have the ability to start grubbing through other systems' ARP tables via SNMP

[Yogeeraj_1]

hi,

not sure it can be done.

try nmap and search through the output

just some thoughts

kind regards
yogeeraj

[Gilles Allard]

You can use the linkloop utility to verify if the machine is reachable. If yes, then do a ping to the broadcast address. The IP addresss should then be in the arp cache.
Example:
linkloop -v 0x0123456789ab
ping 192.168.1.255
arp -a

[rick jones]

My experience thusfar is linkloop will only work if the MAC is associated with another HP-UX system, or perhaps a linux system with the port of linkloop running on it.

As more and more systems get configured to not respond to broadcast pings, the efficacy of pinging the broadcast address is diminishing.

If the system with the MAC is going to be willing to respond to the broadcast ping, might as well just start with the broadcast ping and bypass the linkloop step (IMO). Yes, the linkloop would suggest that sending the ping isn't useful, but given the chances of a false negative based on the first paragraph, even if one doesn't get a response to linkloop, it is probably still no less worthwhile to issue the ping.

[Heironimus]

If you're going to need this type of information on a frequent/ongoing basis, you may want to look in to installing "arpwatch" (or a similar tool) somewhere in your network. It snoops ARP traffic and records the MAC and IP of systems it sees to a flat file.

Inverse ARP is the network protocol for requesting the information, but I think very few network systems have real use for it (ATM, maybe?) so most vendors don't even implement it in their IP stacks.

Reverse ARP (rarp/rarpd) is an old protocol for assigning IPs and network booting, as I recall it actually predates bootp. It wouldn't help with this because rarpd generally looks up the information out of static files in /etc.