Re: Getting the ethernet address
Re: Getting the ethernet address
- Subject: Re: Getting the ethernet address
- From: Josh Graessley <email@hidden>
- Date: Wed, 1 Jun 2005 10:27:53 -0700
On Mac OS X, the arp table is actually implemented as extra data
hanging off of the routing table. My apologies for the confusion when
I suggested looking up the MAC address in the routing table instead
of the arp table. Too many hours spent tramping through kernel code I
suppose.
When a packet is sent, the routing table is consulted to find a route
to the destination. If the route that comes back is a route through a
router instead of directly to another host on a local network, the
route to that router is looked up. In the case of a host or router on
ethernet, that route will have the link layer (arp) information
hanging off of it. We don't have to go look up the arp entry in a
separate table. If we don't have an arp entry yet, we will allocate
one, queue the packet, and send an arp query on the appropriate
interface. The packet will be transmitted when the ARP response is
received.
-josh
On Jun 1, 2005, at 6:12 AM, Peter Paulus wrote:
Hello all,
You'd actually be looking ethernet address up in the ARP (Address
Resolution Protocol) table, which holds (ip-address, ethernet-
address) tuples. You'll only find ip-adresses in the table that are
on the same network as the particular host you're running from. For
ip-destinations on other networks, you will not find any entries.
This is because of the way IP works.
For normal address ranges (Class A, B, and C), the ip-stack first
determines if the source-ip-network is the same network as the
destination-ip-network, using the netmask. If that is the case the
destination-ip-address is looked up in the arp-table.
If it is in the arp-table, the associated ethernet-address is used
as the destination-ethernet-address in the packet. If the
destination-ip-address is not in the arp-table then an ARP-request
(broadcast) is sent over the network. The ARP-request asks for the
ethernet-address associated with the designated ip-address. The
host holding this ip-address replies (unicast) to the requesting
host, supplying the ethernet-address it was looking for. The
requesting host then caches the ip-address, ethernet-address tuple
in his arp-table. If there is no answer from any station you will
an 'Host unreachable' from your local ip-stack.
If the destination-ip-address is missing from the table, the ip-
stack determines if there is a default gateway set. If that is the
case the ip-address of the default gateway is looked up in the arp-
table. The rest of the processing is the same as in the above
paragraph. The net effect is that for ip-destinations on other
networks the ethernet-address of the default gateway is used. As
the packet travels across the network this scheme is repeated. Thus
the ethernet-address in the packet is replaced by a different one,
each time a packet traverses a router. Also the router replaces the
source ethernet-address with it's own (i.e. the ethernet-address of
the interface it is sending the packet out in).
If a host has multiple interface, I guess the routing table is
consulted first. I''m not quite sure about that because the ip-
stack could also send it to the default gateway, where the default
gateway redirects to the gateway holding the shortest path to the
destination-ip-address.
The holds for host with multiple interfaces and having a routing
protocol (e.g. RIP) active.
This is the reason that, generally, there is not much use for
trying to get the ethernet-address from a packet. The ethernet-
address is rather volatile.
The arp-table has a time-out of, I think, normally 20 minutes. If
you're host hasn't used a ethernet-address in the table for 20
minutes the entry is cleared from the table. Normal resulution then
starts as soon as you resume sending to that destination-ip-address.
You can create static arp entries in the table. That has saved an
occaisional day. I would not recommend that for normal operation. I
used it a few times when setting up a network. I do not know the
specifics any more; too long ago.
As for why you would want this: The only thing I can think of right
now is that you may want to determine which route the packet used.
I guess you don't need the ethernet-address for that. You have the
source-ip-address of the packet. You can consult the routing table
to find the route it came in on. (In general the route that is
used from you to them will also be used for the return path. The IP
protocol leaves that open. Every router makes it's own decisions.
The from-path does not have to be the same as the to-path. So in
the end I'm not sure what you can deduce from the route that is
treveled in the network. If you want to determine whether the
destination-ip-address is local you can do that from network
adresses alone. Hold the netmask against the destination-ip-
address. Hold the netmask against you own ip-address. If that
results in the same network, the peer is local.
Open a unix shell and type arp -a to see the table.
Use netstat -r to see the routing table.
With kind regards,
Peter Paulus
The routing table is used for different purposes and holds (ip-
address, (interface, metrics)) tuples
On Wednesday, Jun 1, 2005, at 00:43 Europe/Amsterdam, Josh
Graessley wrote:
The hardware address of the packet is not available to the
application. Why do you want to do this?
You can look up the MAC address for various IP address in the routing
table. You can look at the source for the arp command to see how to
do this.
You can use getifaddrs <x-man-page://3/getifaddrs> to get the MAC
address for the various interfaces on the local machine.
-josh
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden