In article , ProgDario wrote: :I have two input parameters: [DHCP Server address] and [Some device MAC :address].
:I have to write a Java class that retrieves the ARP table from a DHCP :remote server by knowing its IP ADDRESS.
:Then, with the ARP TABLE listed, I have to extract the IP ADDRESS of a :device by knowing the MAC Address.
The DHCP server is not necessarily going to have still have the appropriate ARP entry in it's tables. DHCP tables are stored seperately than ARP tables. ARP tables are used to figure out how to communicate with a device, but if the host (or phone) does not happen to talk to the DHCP server for awhile, the ARP entry might time out.
If you need to find the IP address even when the MAC might have been quiet for awhile, then you are going to have to find some way to query the DHCP server DHCP tables. That's not necessarily possible at all, and when possible might involve parsing HTML output or similar tedious chores in the general case. [I didn't look back to see whether there was a constraint on what the DHCP server is.]
If the device is active, then you would likely find it easier to do some SNMP queries of the local [managed] router, rather than of the DHCP server.
On a router-like device, you should snmpwalk the OID .1.3.6.1.2.1.4.22.1.2 and parse the outputs, which may look something like
.1.3.6.1.2.1.4.22.1.2.260.172.16.0.1 = 0:e0:16:99:1d:84
Find the line that matches the MAC you are interested in. Note that different devices might or might not supress leading 0's in the MAC, and note that different devices might use a different delimiter such as - instead of : between the parts. Possibly some devices use uppercase instead of lower case, or use spaces between the parts (I haven't personally seen either of those cases for -this- OID, but both are common when look at a different OID for switches). The output could have ended with
00-e0-16-99-1d-84 instead of 0:e0:16:99:1d:84 so make sure that you know how your device transforms the MACs and adjust your search strategy accordingly.
Once you have found the line that ends in the correct MAC, then the last 4 portions of the OID are the IP address -- 172.16.0.1 in this example. The portion immediately before that, 260 in this example, is a location code. On some routers, this location code is an index to the VLAN table, and in other routers it encodes additional information. For example, on a Nortel Passport/Accelar 1200 series, it encodes the module number, port number, and an index into a VLAN table. You may not care now about the location code, but when you are attempting to *find* the IP phone, you will find the location code to be an essential linkage.
The general task of tracing down a MAC through a chain of devices is messy and often involves model-line specific code (especially for switches.)