Looking for source code (Get Mac address from IP address)
SpreadTooThin
What I'm looking for is unix source code of a method to get the mac
address of a computer given its IP / host name.
C/C++. Or a good tutorial...
TIA.
Martijn Lievaart
Something like (untested):
#/bin/sh
ping -n 1 <ip> >/dev/null 2>&1
arp -a | fgrep <ip>
M4
SpreadTooThin
> On Tue, 20 Jan 2009 19:47:23 +0100, Martijn Lievaart wrote:
> >> I think this is like an arp request... What I'm looking for is unix
> >> source code of a method to get the mac address of a computer given its
> >> IP / host name. C/C++. Or a good tutorial...
> >> TIA.
>
> > Something like (untested):
>
> > #/bin/sh
> > ping -n 1 <ip> >/dev/null 2>&1
> > arp -a | fgrep <ip>
>
>
> To answer to the OP, I found this using google :
>
> http://outflux.net/software/shorts/c/hw_get.c
Correct me if I'm wrong but isn't this getting the MAC address of the
local machine and not based on the IP address?
Vernon Schryver
SpreadTooThin <bjobr...@gmail.com> wrote:
>> > ping -n 1 <ip> >/dev/null 2>&1
>> > arp -a | fgrep <ip>
>>
>> It is not C/C++ but shell script
One might use the system() library function or more direct calls
to pipe(), fork(), and exec().
On 4.4BSD related systems with route sockets, you could use routing
sockets. For example C that does that, see the `route -v get` or
`netstat -rn` commands in 4.4BSD related systems.
>> To answer to the OP, I found this using googl:
>>
>> http://outflux.net/software/shorts/c/hw_get.c
>
>Correct me if I'm wrong but isn't this getting the MAC address of the
>local machine and not based on the IP address?
It also depends on the local machine support ioctl(SIOCGIFHWADDR).
Other mechanisms are required to do the same thing on other flavors of
UNIX-like systems, not to mention non-UNIX-like systems that claim
to support some version of POSIX.
The original goal to "get MAC address from IP address" cannot be done
except on the local machine without some network chatter, and even then
it generally can only be done for IP addresses on the directly connected
local area network, and then only in most cases. You usually must
convince the machine that is using the target IP address (or a proxy
for it) to tell you one of its MAC addresses. (It might be using a
single IP address with more than one MAC address, or vice versa.)
The first of those two shell commands trick the local system into doing
the network chitchat, by asking it to send an ICMP Echo-Request packet
to the IP address. If the IP address is on the local network and the
network is the right kind of LAN, the local system will probably (but not
necessarily) use the ARP protocol to ask for MAC address corresponding to
the target IP address. (There LANs other than 802.3 as well as 802.3
LANs that use other schemes such as static tables for various reasons
often under a heading of "security.")
The second shell command (or pipeline) asks the local system to dump
its entire table of IP corresponding MAC addresses. Instead of using
`grep` to look for the address, I would probably do something like
IP=10.2.3.4
arp -n $IP | sed -e 's/.*\(no entry\)/\1/' -e 's/.*\([0-9a-f:]\{17\}\).*/\1/'
Vernon Schryver v...@rhyolite.com
Mark Wooding
> Correct me if I'm wrong but isn't this getting the MAC address of the
> local machine and not based on the IP address?
Looks like it to me. I think to do the job wanted, you need to mess
with PF_NETLINK (Linux) or PF_ROUTE (BSD) sockets, or some ioctl(2)
mess, or, if you're really unlucky, a /dev/kmem nightmare. Reading the
output of arp(8) is certainly less sexy, but it seems somewhat more
practical.
(At least until you look at the differences between all the various
systems' arp(8) outputs...)
-- [mdw]
David Schwartz
> Correct me if I'm wrong but isn't this getting the MAC address of the
> local machine and not based on the IP address?
No, this is correct. You just want to use 'arp -an' so you don't wait
for DNS.
DS
Philip Paeps
> I think this is like an arp request...
Yes. So it will only work for IPs on your local network.
> What I'm looking for is unix source code of a method to get the mac address
> of a computer given its IP / host name.
Depending on the Unix you're using, you may need to fight the kernel to be
able to do this. It may be tempting to try using a raw socket on the
interface with an address on the same network as the one you're interested in,
but you may find that the kernel will eat the answers instead of sending them
up the socket.
First you will need to find an interface on the same network as the IP you are
interested in. The SIOCGIFCONF and SIOCGIFNETMASK ioctls are probably what
you want. Example code can probably be found in any old arp implementation.
On a BSDish system -- or another system which implements BPF -- the easiest
way to send your ARP requests and get the answers will probably be to use the
BPF.
Sending your request will be a simple matter of creating an Ethernet header
and sticking an ARP behind it. Take a look at struct ether_header and struct
ether_arp. You should just be able to write that to your BPF descriptor.
Getting the replies will be a bit more interesting. A filter like this should
catch them: (not tested)
struct bpf_insn insns[] = {
BPF_STMT(BPF_LD|BPF_H|BPF_ABS, 12),
BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, ETHERTYPE_ARP, 0, 3),
BPF_STMT(BPF_LD|BPF_H|BPF_ABS, 20),
BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, ARPOP_REPLY, 0, 1),
BPF_STMT(BPF_RET|BPF_K, sizeof(struct ether_arp) +
sizeof(struct ether_header)),
BPF_STMT(BPF_RET|BPF_K, 0),
};
Good luck. :-)
- Philip
--
Philip Paeps Please don't email any replies
phi...@paeps.cx I follow the newsgroup.
Nanny could get a statue to cry on her shoulder and say what it really
thought about pigeons.
-- (Terry Pratchett, Maskerade)
SpreadTooThin
I've looked around and I've yet to be able to find an implementation
of arp.c that compiles on MAC OS X.
Philip Paeps
Well ... yes. Such is the nature of example code. The trick is trying to
understand what the code does on the system it was written for and using that
information to figure out what you'll need to do on your system. While if
would be nice if "example code" just worked everywhere, the real world is not
like that. Some headscratching is required.
Vernon Schryver
Philip Paeps <philip...@paeps.cx> wrote:
>SpreadTooThin <bjobr...@gmail.com> wrote:
>>> Example code can probably be found in any old arp implementation.
>>
>> I've looked around and I've yet to be able to find an implementation
>> of arp.c that compiles on MAC OS X.
>
>Well ... yes. Such is the nature of example code. The trick is trying to
>understand what the code does on the system it was written for and using that
>information to figure out what you'll need to do on your system. While if
>would be nice if "example code" just worked everywhere, the real world is not
>like that. Some headscratching is required.
That certainly seems required in this case where arp.c would not get a
MAC address from an IP address but only look for a MAC address for an IP
address that happens to already and still be in the kernel's table.
Arp.c, or at least versions of something like
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/arp/arp.c?rev=1.70
has nothing to with the ARP protocol or really discovering the MAC address
for an IP address. Really discovering at MAC address is more related
to something like
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/if_ether.c?rev=1.190
and points south.
Instead of diving into the source, it might be better to ask the Oracle
with something like
http://www.google.com/search?q=address+resolution+protocol+arp
or consult Stevens' "TCP/IP Illustrated"
http://www.google.com/search?q=rich+stevens+arp
By the way, given the rumored base of much of MAC OS X, if I could not
get source from Apple, I might start with those FreeBSD CVS archives.
It might be best to start with some of the hits for
http://www.google.com/search?q=mac+os+x+arp
such as the hit labeled "Find local network devices ..." or the later
hit with the summary
ArpSpyX is an OS X ARP packet sniffer. It will display a list of
IP and MAC addresses found by analyzing arp traffic on your network.
Vernon Schryver v...@rhyolite.com
SpreadTooThin
There is intelligent life.
sg
> In article <cf4b2f2b-1682-4151-a84d-3fb9d736f...@d36g2000prf.googlegroups.com>,
If it on Linux system we can use the arping <ip address> this will
give the mac address. The arping implementation is what you must be
looking for.
-SG
Vernon Schryver
sg <gautams...@gmail.com> wrote:
>If it on Linux system we can use the arping <ip address> this will
>give the mac address. The arping implementation is what you must be
>looking for.
That is wrong for at least some Linux systems, as you can see by reading
the friendly man pages. For example,
http://www.google.com/search?q=arp+linux
http://linux.about.com/library/cmd/blcmdl8_arp.htm
says the Linux arp command does just what I said:
Arp manipulates the kernel's ARP cache in various ways. The primary
options are clearing an address mapping entry and manually setting
up one. For debugging purposes, the arp program also allows a
complete dump of the ARP cache.
If the kernel does not already have the MAC address for an IP address
such as 10.2.3.4, then
% arp -n 10.2.3.4
will say
10.2.3.4 (10.2.3.4) -- no entry
Of course, after `ping 10.2.3.4` (or anything else that needs to talk to
10.2.3.4 on the local network) and the kernel's arp code has done the
address resolution protocol or ARP chatter, you get something like
% arp -n 10.2.3.4
Address HWtype HWaddress Flags Mask Iface
10.2.3.4 ether 01:23:45:56:78:ab C eth0
I just now tested that on a SUSE box where `uname -a` says in
"part 2.6.11.4-21.2-default" using the IP address of a system that
is alive on my internal network but not in the ARP table of the Linux box.
I censored the IP and MAC addresses in both `arp` output examples
after cutting and pasting.
Vernon Schryver v...@rhyolite.com
sg
> In article <bd8a357d-9bf7-4453-886d-01f592610...@d36g2000prf.googlegroups.com>,
>
> sg <gautams.for...@gmail.com> wrote:
> >If it on Linux system we can use the arping <ip address> this will
> >give the mac address. The arping implementation is what you must be
> >looking for.
>
> That is wrong for at least some Linux systems, as you can see by reading
> says the Linux arp command does just what I said:
>
> Arp manipulates the kernel's ARP cache in various ways. The primary
> options are clearing an address mapping entry and manually setting
> up one. For debugging purposes, the arp program also allows a
> complete dump of the ARP cache.
>
> If the kernel does not already have the MAC address for an IP address
> such as 10.2.3.4, then
> % arp -n 10.2.3.4
> will say
> 10.2.3.4 (10.2.3.4) -- no entry
>
> Of course, after `ping 10.2.3.4` (or anything else that needs to talk to
> 10.2.3.4 on the local network) and the kernel's arp code has done the
> address resolution protocol or ARP chatter, you get something like
>
> % arp -n 10.2.3.4
> Address HWtype HWaddress Flags Mask Iface
> 10.2.3.4 ether 01:23:45:56:78:ab C eth0
>
> I just now tested that on a SUSE box where `uname -a` says in
> "part 2.6.11.4-21.2-default" using the IP address of a system that
> is alive on my internal network but not in the ARP table of the Linux box.
> I censored the IP and MAC addresses in both `arp` output examples
> after cutting and pasting.
>
> Vernon Schryver v...@rhyolite.com
Hi,
The information about arp what you have described is correct. I was
referring to a command called as 'arping' which can give you the MAC
address of the remote host if it's up and has a IP. You can have a
look at this link
http://en.wikipedia.org/wiki/Arping
-SG
Vernon Schryver
sg <gautams...@gmail.com> wrote:
>The information about arp what you have described is correct. I was
>referring to a command called as 'arping' which can give you the MAC
>address of the remote host if it's up and has a IP. You can have a
>look at this link
>http://en.wikipedia.org/wiki/Arping
Interesting. That web page points to
http://www.habets.pp.se/synscan/programs.php?prog=arping
which claims source that builds on MAC OS X.
It belatedly occurred to me that no one has asked why an application
needs the MAC address corresponding to an IP address. Such needs
are rarely real, and when real, often best ignored.
Vernon Schryver v...@rhyolite.com