get MAC Address from IP

[Guest]

Hi,
I want to get the mac address from a machine, which i have the IP address of
that machine, how can i do that?
I know how to get the mac address of the local machine from the following
code:

Dim mc As System.Management.ManagementClass
Dim mo As System.Management.ManagementObject
mc = New
System.Management.ManagementClass("Win32_NetworkAdapterConfiguration")
Dim moc As System.Management.ManagementObjectCollection =
mc.GetInstances()

For Each mo In moc
If mo.Item("IPEnabled") = True Then
MsgBox(mo.Item("MacAddress").ToString())
End If
Next

Thanks!

 

[John Saunders]

Hi,
I want to get the mac address from a machine, which i have the IP address
of
that machine, how can i do that?

You can't. There's no relationship between the two.

And besides, a machine may have multiple IP addresses and multiple MAC
addresses.

John Saunders

 

[Shiva]

You might want to try this code. But, its not tested fully (works in the
local network though).

[DllImport("iphlpapi.dll", ExactSpelling=true)]
public static extern int SendARP( int DestIP, int SrcIP, [Out] byte[]
pMacAddr, ref int PhyAddrLen );

IPAddress ip = IPAddress.Parse("10.0.x.x"); // Actual IP
int rv;
string macStr;
byte[] mac = new byte[6];
int maclen = mac.Length;

rv = SendARP(BitConverter.ToInt32(ip.GetAddressBytes(), 0), 0, mac, ref
maclen);
if (rv == 0) // If not 0, error
{
macStr = BitConverter.ToString(mac, 0, 6);
Console.WriteLine (macStr);
}

Hi,
I want to get the mac address from a machine, which i have the IP address of
that machine, how can i do that?
I know how to get the mac address of the local machine from the following
code:

Dim mc As System.Management.ManagementClass
Dim mo As System.Management.ManagementObject
mc = New
System.Management.ManagementClass("Win32_NetworkAdapterConfiguration")
Dim moc As System.Management.ManagementObjectCollection =
mc.GetInstances()

For Each mo In moc
If mo.Item("IPEnabled") = True Then
MsgBox(mo.Item("MacAddress").ToString())
End If
Next

Thanks!

 

[Gareth Watson]

You can't. There's no relationship between the two.

And besides, a machine may have multiple IP addresses and multiple MAC
addresses.

John Saunders

No relationship between MAC address and IP address? Did I read that right!
Of course there's a relationship how else would you move from layer 3 (IP)
to layer 2 (MAC).

In fact there is a whole protocol for this conversion. Its called ARP.

Basically ARP broadcasts on the segment asking all the devices to repond
with their MAC if they own the stated IP. This is a simplification of the
process but it is basically what happens.

I have no idea how to do this in .Net but saying there is no relationship is
clearly not the case.

Of course I may have misread your post but its all good factual stuff
anyway.

Cheers,

Gareth.

 

[John Saunders]

No relationship between MAC address and IP address? Did I read that
right! Of course there's a relationship how else would you move from layer
3 (IP) to layer 2 (MAC).

In fact there is a whole protocol for this conversion. Its called ARP.

Basically ARP broadcasts on the segment asking all the devices to repond
with their MAC if they own the stated IP. This is a simplification of the
process but it is basically what happens.

I have no idea how to do this in .Net but saying there is no relationship
is clearly not the case.

Do this thought experiment.

1) ARP for the MAC address associated with a given IP address (*). Call the
result "m".
2) Now, once again ARP for the MAC address, calling the result "m'".

Question: under what circumstances will m = m'?

If your code lives in a world where those circumstances will always apply,
then for your code, there is a relationship between IP address and MAC
address. But in general, m may not be the same as m', which means that, in
general, there is no useful relationship between IP address and MAC address.

Also, IN GENERAL, it's a bad idea for code which is not running the network
to screw with network "stuff" like IP addresses (also routes, etc). If the
code isn't running the network, then it has no idea when the network will
decide to pull the assumptions out from under its feet.

As an example, consider code that treats the IP address as the identity of a
machine. That code will be disappointed when the machine loses its DHCP
lease and starts using a different IP address. Strangely, DHCP didn't bother
telling the code that the network had decided to change implementation
specifics. Note that the network layer won't be troubled by this change, but
this hypothetical code _will_ be.

This rant is probably just a sign that I'm getting old, but you might want
to consider the different layers of a network like different classes in an
OO design. Class "EndApplication" shouldn't be using nor depending on
private members of class "Network". In fact, there's some reason to doubt
that class "EndApplication" should even know of the existance of class
"Network".

John Saunders

(*) I presume you realize that ARP is not a routed protocol? You can't use
it at all for a machine not on the same logical network segment. Even on the
same logical segment, you may not be able to use it on all hosts, as
something at the Network/Datalink layer may block ARP traffic.

 

[Gareth Watson]

Do this thought experiment.

1) ARP for the MAC address associated with a given IP address (*). Call
the result "m".
2) Now, once again ARP for the MAC address, calling the result "m'".

Question: under what circumstances will m = m'?

If your code lives in a world where those circumstances will always apply,
then for your code, there is a relationship between IP address and MAC
address. But in general, m may not be the same as m', which means that, in
general, there is no useful relationship between IP address and MAC
address.

Also, IN GENERAL, it's a bad idea for code which is not running the
network to screw with network "stuff" like IP addresses (also routes,
etc). If the code isn't running the network, then it has no idea when the
network will decide to pull the assumptions out from under its feet.

As an example, consider code that treats the IP address as the identity of
a machine. That code will be disappointed when the machine loses its DHCP
lease and starts using a different IP address. Strangely, DHCP didn't
bother telling the code that the network had decided to change
implementation specifics. Note that the network layer won't be troubled by
this change, but this hypothetical code _will_ be.

This rant is probably just a sign that I'm getting old, but you might want
to consider the different layers of a network like different classes in an
OO design. Class "EndApplication" shouldn't be using nor depending on
private members of class "Network". In fact, there's some reason to doubt
that class "EndApplication" should even know of the existance of class
"Network".

John Saunders

(*) I presume you realize that ARP is not a routed protocol? You can't use
it at all for a machine not on the same logical network segment. Even on
the same logical segment, you may not be able to use it on all hosts, as
something at the Network/Datalink layer may block ARP traffic.

Oh dear. I think we both understand that MAC addresses and IP addresses can
change. Two examples, changing the NIC on my server changes the MAC but not
the IP. Changing the IP associated a NIC does not change the MAC. ARP is
used to join the two together, it makes is possible for me to change a NIC
and keep the same IP safe in the knowledge that traffic destined to the
server will reach it sucessfully.

We cannot assume anything especially m=m. We can however find a MAC
associated with an IP and be sure it is correct. We cannot however be sure
how long that information will be valid. This is why the ARP cache, at
least on a 2000 box, has a 5 second timeout on its entries. This timeout is
a lot shorter than that of many networking applications so a change in a MAC
address is not noticed by the application.

How an application uses this information is irrelevant. If a developer does
not fully understand how the networking layer works and their app fails,
tough luck.

This does not however invalidate the argument that MAC and IP addresses are
related. The conversion between the two is necessary component of an
IP/Ethernet network hence the necessity for ARP. On their own IP's and MACs
mean nothing, ARP is the relationship between the two.

The layers are of course seperate, we could swap layer 2 for a system that
does not use MACs and IP could still run over it. However not matter what
system is employed the movement between layers is still required. Hence a
relationship between the layers. In OO design this would be known as an
Interface. No one cares about what goes on behind the Interface just that
the Interface is known.

So a relationship between IP and MAC exists because of the standard
Interface between Layer 3 and Layer 2. You can change Layer 2 to whatever
you like but still a relationship will exist because of the Interface. In
our instance ARP is the Interface. ARP for example is available in a number
of Layer 2 systems Ethernet and Token Ring networks make use of it. So
switching between the two is possible (in practice this would be a darn
sight more than ticking a box ).

I hope this makes things clearer. A relationship must exist between Layer 3
and Layer 2. In our case it is ARP. If a relationship exists between Layer
3 and 2 then by implication a relationship between IP and MAC must also
exist.

Cheers,

Gareth.

 

[John Saunders]

....
Oh dear. I think we both understand that MAC addresses and IP addresses
can change. Two examples, changing the NIC on my server changes the MAC
but not the IP. Changing the IP associated a NIC does not change the MAC.
ARP is used to join the two together, it makes is possible for me to
change a NIC and keep the same IP safe in the knowledge that traffic
destined to the server will reach it sucessfully.

Good Luck, Mr. Watson. I hope you manage to do well in your universe. In the
real world, things aren't quite as simple as you seem to believe.

If you're lucky, you'll be working somewhere else when your code falls over
dead after the Network layer makes an implementation decision with which
your code does not agree.

John Saunders

P.S. You wouldn't happen to recall how much code needed to change in order
to handle dynamic IP addresses, would you ("What do you _mean_ the address
can change?")

Do you recall assumptions needing to change when NAT boxes became prevalent?
("Wait now, the machine has only a single NIC, yet I'm seeing connections
from it using multiple IP addresses?")

When you assume, you leave Murphy's Law an opening.

 

[Gareth Watson]

Good Luck, Mr. Watson. I hope you manage to do well in your universe. In
the real world, things aren't quite as simple as you seem to believe.

If you're lucky, you'll be working somewhere else when your code falls
over dead after the Network layer makes an implementation decision with
which your code does not agree.

John Saunders

P.S. You wouldn't happen to recall how much code needed to change in order
to handle dynamic IP addresses, would you ("What do you _mean_ the address
can change?")

Do you recall assumptions needing to change when NAT boxes became
prevalent? ("Wait now, the machine has only a single NIC, yet I'm seeing
connections from it using multiple IP addresses?")

When you assume, you leave Murphy's Law an opening.

I was hoping this conversation would not degenerate into perosnal attacks.
Still if you only argument now is with the quality of code I produce then I
can only think you agree with my points above.

I never said any of this was simple! I am only concerned with the
relationship between MAC and IP. Complexity has nothing to do with whether
the relationship exists or not. I have many complex relationships in my
life but they still exist none-the-less

Maybe the problem is that you're focusing on the result rather than the
process. I am not arguing about the validity of the information gained by
an application, just that a relationship between IP and MAC exists. Whether
you think that the product of the relationship is useless or not is
irrelevant.

Part of me suspects this all boils down to semantics. Maybe relationship is
the wrong word to use. Can you think of any others you would be more
comfortable with?

Anyway, I hope you don't feel this is a personal attack on you, I hope you
see it as I do, a healthy debate.

Cheers,

Gareth.

 

[John Saunders]

I was hoping this conversation would not degenerate into perosnal attacks.

Huh? How does a comment on Murphy's Law constitute a personal attack? I
suppose it might be "personal" to ask what you "personally" remember?

Still if you only argument now is with the quality of code I produce then
I can only think you agree with my points above.

What did I say about the quality of your code? Your code could be perfect,
but if your assumptions become invalid, the program will fail - by doing
exactly what you told it to do.

I never said any of this was simple! I am only concerned with the
relationship between MAC and IP. Complexity has nothing to do with
whether the relationship exists or not. I have many complex relationships
in my life but they still exist none-the-less

Maybe the problem is that you're focusing on the result rather than the
process. I am not arguing about the validity of the information gained by
an application, just that a relationship between IP and MAC exists.
Whether you think that the product of the relationship is useless or not
is irrelevant.

My argument was that the relationship is more complicated than you have
stated, and that the nature of the relationship is such than an application
should not be using this relationship at all. The only exceptions would be
applications which are actually in the Network layer, or applications which
are an adjunct to the Network layer, like diagnostics programs.

Part of me suspects this all boils down to semantics. Maybe relationship
is the wrong word to use. Can you think of any others you would be more
comfortable with?

Anyway, I hope you don't feel this is a personal attack on you, I hope you
see it as I do, a healthy debate.

I don't know, maybe it's an age thing. I've lived long enough to find a
number of my stupid assumptions rendered, well, stupid. I learned TCP/IP
before DHCP and before NAT, and found that I had made a number of false
assumptions about how the Network layer is designed. What I learned from
this experience was that I shouldn't have been making _any_ assumptions
about the Network layer, since it was not my code, and I was not a part of
it. Neither DHCP nor NAT violated the "contract" between the Network layer
and I, because there _was_ no such contract! If TCP was happy, then I should
have been happy as well.

You have decided to assume that ARP will continue to give you good results.
It may be that you will continue to get good results over the lifetime of
your application. As long as your application does not survive the accuracy
of your assuptions, you'll do fine.

But I, personally, wouldn't bake those assumptions into code that will still
be running in a few years' time. Experience suggests that there may be
Network layer changes that I won't find out about until too late.


John Saunders