Determining IP address from MAC address

Hi,

I have a MAC address for a given system and need to be able to
programatically determine it's IP address for use with a TCP-IP based
application. Clearly, the ip address might be in the arp table for ced
host but the problem occurs when it is not. The options as I see it
are

1) broadcast ping (programmatically horrible as every host on the
network will respond)
2) inverse arp lookup

My questions are:

1) Does linux support the inverse arp protocol, as various resources
I've seen indicate it is primarily used for frame relay? If so could
you direct me to the appropriate resources as I've been unable to
determine if linux supports this.

2) What other methods could I use to obtain this information?

Regards
Ian Neal

On 12 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed). com>, (E-Mail Removed)
wrote:

>1) broadcast ping (programmatically horrible as every host on the
>network will respond)

That also depends on the O/S - some like late versions of windoze won't
respond to a broadcast ping - and configuration - some people firewall
broadcast pings, some ignore pings entirely.

>2) inverse arp lookup

That may be a problem

>1) Does linux support the inverse arp protocol, as various resources
>I've seen indicate it is primarily used for frame relay? If so could
>you direct me to the appropriate resources as I've been unable to
>determine if linux supports this.

[compton ~]$ whatis rarp
rarp (8) - manipulate the system RARP table
[compton ~]$

0903 A Reverse Address Resolution Protocol. R. Finlayson, T. Mann,
J.C. Mogul, M. Theimer. June 1984. (Format: TXT=9345 bytes) (Also
STD0038) (Status: STANDARD)

The problem with RARP is that it requires a server that has a list of
MAC address to IP addresses. Unfortunately, there is no equivalent of
ARP going in the opposite direction (ARP who-has 00:20:AF:56:9D:EE tell
192.0.2.11 at 08:00:20:EA:81:4A). Sorry.

>2) What other methods could I use to obtain this information?

The way the RARP server works is an /etc/ethers file that lists the MAC
address and hostname (or IP address or both).

Another method would be to use a technique like hping2 to ping the
MAC address.

If ping is blocked, and you can send raw Ethernet frames, send a packet
of some kind (example, TCP packet to some high port number with a b0rked
IP address) and see if the peer will reply with an RST, but containing
the correct IP address.

"Be inventive" ;-)

Old guy

True, firewalls and various os'es don't respond to broadcast pings.

Hping2 doesn't seem to support pinging by MAC address at least not
according to the latest development version.

The only option as I see it is to send an inverse arp packet by sending
an ethernet fragment, however, I'm not convinced that any operating
systems support responding to this protocol.

Anyone know if the major *nix oses (Linux, AIX, Windows,HP-UX, AIX ...)
support the inverse arp protocol?

TIA


Moe Trin wrote:
> On 12 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article
> <(E-Mail Removed). com>, (E-Mail Removed)
> wrote:
>
> >1) broadcast ping (programmatically horrible as every host on the
> >network will respond)
>
> That also depends on the O/S - some like late versions of windoze won't
> respond to a broadcast ping - and configuration - some people firewall
> broadcast pings, some ignore pings entirely.
>
> >2) inverse arp lookup
>
> That may be a problem
>
> >1) Does linux support the inverse arp protocol, as various resources
> >I've seen indicate it is primarily used for frame relay? If so could
> >you direct me to the appropriate resources as I've been unable to
> >determine if linux supports this.
>
> [compton ~]$ whatis rarp
> rarp (8) - manipulate the system RARP table
> [compton ~]$
>
> 0903 A Reverse Address Resolution Protocol. R. Finlayson, T. Mann,
> J.C. Mogul, M. Theimer. June 1984. (Format: TXT=9345 bytes) (Also
> STD0038) (Status: STANDARD)
>
> The problem with RARP is that it requires a server that has a list of
> MAC address to IP addresses. Unfortunately, there is no equivalent of
> ARP going in the opposite direction (ARP who-has 00:20:AF:56:9D:EE tell
> 192.0.2.11 at 08:00:20:EA:81:4A). Sorry.
>
> >2) What other methods could I use to obtain this information?
>
> The way the RARP server works is an /etc/ethers file that lists the MAC
> address and hostname (or IP address or both).
>
> Another method would be to use a technique like hping2 to ping the
> MAC address.
>
> If ping is blocked, and you can send raw Ethernet frames, send a packet
> of some kind (example, TCP packet to some high port number with a b0rked
> IP address) and see if the peer will reply with an RST, but containing
> the correct IP address.
>
> "Be inventive" ;-)
>
> Old guy

On 14 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) om>, (E-Mail Removed) wrote:

>True, firewalls and various os'es don't respond to broadcast pings.
>
>Hping2 doesn't seem to support pinging by MAC address at least not
>according to the latest development version.

Sorry about that. Let's try again:

[compton ~]$ whatis hping2 arping
hping2 (8) - send (almost) arbitrary TCP/IP packets to network hosts
arping (8) - sends arp and/or ip pings to a given host
[compton ~]$

I've got way to many network tools on these systems.

>The only option as I see it is to send an inverse arp packet by sending
>an ethernet fragment, however, I'm not convinced that any operating
>systems support responding to this protocol.

What do you define as an inverse arp packet? This isn't defined by any
RFC, nor does it appear in the latest Ethernet numbers document
(http://www.iana.org/assignments/ethernet-numbers). I'd suggest that
if you don't want to maintain an /etc/ethers file, that arping might
do it, or as last resort try sending a packet to the MAC address with
a bogus (or broadcast) IP address, and hope that the remote system isn't
blocking ICMP Type 3 or 'RST' packets.

Old guy

Inverse Arp protocol is RFC 2390. Arping could probably be modified to
support sending and inverse arp request packet requesting the mac
address of interest. Unfortunately, it remains to be seen in any of
the oses will respond to this.



Moe Trin wrote:
> On 14 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article
> <(E-Mail Removed) om>, (E-Mail Removed) wrote:
>
> >True, firewalls and various os'es don't respond to broadcast pings.
> >
> >Hping2 doesn't seem to support pinging by MAC address at least not
> >according to the latest development version.
>
> Sorry about that. Let's try again:
>
> [compton ~]$ whatis hping2 arping
> hping2 (8) - send (almost) arbitrary TCP/IP packets to network hosts
> arping (8) - sends arp and/or ip pings to a given host
> [compton ~]$
>
> I've got way to many network tools on these systems.
>
> >The only option as I see it is to send an inverse arp packet by sending
> >an ethernet fragment, however, I'm not convinced that any operating
> >systems support responding to this protocol.
>
> What do you define as an inverse arp packet? This isn't defined by any
> RFC, nor does it appear in the latest Ethernet numbers document
> (http://www.iana.org/assignments/ethernet-numbers). I'd suggest that
> if you don't want to maintain an /etc/ethers file, that arping might
> do it, or as last resort try sending a packet to the MAC address with
> a bogus (or broadcast) IP address, and hope that the remote system isn't
> blocking ICMP Type 3 or 'RST' packets.
>
> Old guy

Successfully, sent inverse arp request to a Windows system but it never
sent back a response.


(E-Mail Removed) wrote:
> Inverse Arp protocol is RFC 2390. Arping could probably be modified to
> support sending and inverse arp request packet requesting the mac
> address of interest. Unfortunately, it remains to be seen in any of
> the oses will respond to this.
>
>
>
> Moe Trin wrote:
> > On 14 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article
> > <(E-Mail Removed) om>, (E-Mail Removed) wrote:
> >
> > >True, firewalls and various os'es don't respond to broadcast pings.
> > >
> > >Hping2 doesn't seem to support pinging by MAC address at least not
> > >according to the latest development version.
> >
> > Sorry about that. Let's try again:
> >
> > [compton ~]$ whatis hping2 arping
> > hping2 (8) - send (almost) arbitrary TCP/IP packets to network hosts
> > arping (8) - sends arp and/or ip pings to a given host
> > [compton ~]$
> >
> > I've got way to many network tools on these systems.
> >
> > >The only option as I see it is to send an inverse arp packet by sending
> > >an ethernet fragment, however, I'm not convinced that any operating
> > >systems support responding to this protocol.
> >
> > What do you define as an inverse arp packet? This isn't defined by any
> > RFC, nor does it appear in the latest Ethernet numbers document
> > (http://www.iana.org/assignments/ethernet-numbers). I'd suggest that
> > if you don't want to maintain an /etc/ethers file, that arping might
> > do it, or as last resort try sending a packet to the MAC address with
> > a bogus (or broadcast) IP address, and hope that the remote system isn't
> > blocking ICMP Type 3 or 'RST' packets.
> >
> > Old guy

On 16 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) .com>, (E-Mail Removed)
wrote:

>Successfully, sent inverse arp request to a Windows system but it never
>sent back a response.

What does that look like on Ethernet?

>(E-Mail Removed) wrote:

which as you pointed out if Frame Relay, not Ethernet.

>>Arping could probably be modified to support sending and inverse arp
>>request packet requesting the mac address of interest. Unfortunately,
>>it remains to be seen in any of the oses will respond to this.

I'd go with the concept of sending a packet to some non-well-known port,
and see if the network stack returns a RST or ICMP Type 3. That would be
the expected response if nothing was listening on that port, and there
were no firewall rules in place. If there is a firewall problem, then
the solution is probably an /etc/ethers type solution.

Old guy