Obtainining IP address using MAC address

[Mark Yedinak]

This question is not LabVIEW specific but does anyone know a way to get a devices IP address using only its MAC address? I can't using DNS since some of the printers will obtain their addresses via BOOTP which will not update the name server. The only certain piece of information that I have is the devices' MAC addresses.

[ShaunR]

if you are running windows then you can go to a command prompt and type in "arp -a".

It will give you the IP to MAC mapping that your PC knows about.

[Mark Yedinak]

if you are running windows then you can go to a command prompt and type in "arp -a".

It will give you the IP to MAC mapping that your PC knows about.

THis only works if the PC has communicated with the device. In the situation I am working the devices will not only be changing their IP addresses but also changing subnets as well. The local ARP tables will not work since the IP address is required to build the ARP table. The ARP protocol is used to obtain the MAC address when you have the IP Address or the device. Unfortunately it is not designed to work the other way. Besides, there is no way in LabVIEW to force an ARP packet to be sent and receive the reply.

[ShaunR]

THis only works if the PC has communicated with the device. In the situation I am working the devices will not only be changing their IP addresses but also changing subnets as well. The local ARP tables will not work since the IP address is required to build the ARP table. The ARP protocol is used to obtain the MAC address when you have the IP Address or the device. Unfortunately it is not designed to work the other way. Besides, there is no way in LabVIEW to force an ARP packet to be sent and receive the reply.

Indeed. The MAC address is a physical assignement (serial number if you like) and the IP address is a logical (arbitrary) assignment by the co-ordinator-usually a DNS server or router. The only thing that knows about the mapping is usually the router (s), or (as you rightly say) the local PC if it has communicated with the device. You can force an update to an ARP cache by pinging, but, the pitfall here though (apart from having to know the IP address first) is that if the ARP cache is on a router, its the routers cache that gets updated not your local one.

What you are trying to do is a bit like knowing someones name and trying to get their house address. You can look them up on the "Electrol Role", but you only have access to your own countrys electral role and they could be anywhere in the world. If they (or you) have already exchanged letters then you have thier address.

I think you will find this a dead end since it could circumvent security. What is it you are trying to do that you have MAC addresses but not IP addresses? Wouldn't it be easier to ask the Admin for the IP address the device has been assigned?

[ned]

If your devices are on your local subnet and respond to broadcast pings, you can ping the local broadcast address (x.x.x.255) which should cause your PC to cache the MAC addresses of all the devices that respond. I'm not sure it solves your problem at all but maybe it helps.

[Mark Yedinak]

I test the network functionality of the embedded firmware for the various bar code and labeling printers my company makes. As for asking the admin for an IP address I am the admin and I manage a test network with 25 VLANs, multiple switches, multiple wireless access points and every possible WiFi security. When testing network securities every security is assigned to its own VLAN (subnet) and when testing securities you are not guaranteed the same address each time you test a given printer. We have too many devices to statically assign all the addresses. In addition, the major problem that we have is that individual printers can run different types of firmware. When a printer is switched from one type of firmware (generally a different printer control language) to another its network settings are defaulted and which can mean it switches in normal network security to the default of no security resulting in a new IP address. I am trying to write an utility that would scrub the network for these printers that changed and reconfigure them to their properly assigned network security. These printers are part of a lab that runs long term network stability tests. Manually reconfiguring every printer is very time consuming and a pain in the butt.

Since I am the admin I am actually looking at the possibility of querying the network switches for this information. I was hoping to avoid this if possible. However that is the path that I am currently investigating.

Side note: The printers do support a broadcast query to identify themselves on the network however there are issues with having this work reliably across subnets, at least when doing the query as a broadcast. Broadcast UDP traffic is not routed across subnets.

[Phillip Brooks]

What sort of DHCP/BOOTP server do you run?

I tried (A LONG TIME AGO) to write a simple DHCP server in LabVIEW. I can't find the code now

I recall that some DHCP servers maintain a disk version of the lease table. After a few Google searches I found the name of the file was dhcpd.leases

[Rolf Kalbermatter]

It would seem you have run into a big problem here. The only instance that knows about the IP address mapping of a dynamically assigned IP adress is the DHCP server that issued that address. The way this is usually solved is, that the specific client is known under a DNS name that it provides to the DHCP server when asking for an IP address. The DHCP server then will inform the DNS server about this new address.

Since this seems no option in your case there are only very few other feasible and sure to work things:

1) adding some address recovery support to the devices yourself.

Basically this would be some UDP broadcast message that your devices reacts too. The device will expect a specifically formatted packet on a well defined port. The package could contain a specific MAC address or a place holder to let all devices that receive it respond with a packet that contains the MAC address and the current IP address. This is obviously something most device manufacturers do not make public but since you are to test devices that your company manufacturers this should not be the problem.

Since UDP braodcasts are usually not routed, you can get in trouble with this in a setup with multiple IP subnets and would need to use TCP instead but that does not have an universal broadcast mechanisme like UDP.

2) Another solution is to simply add some remote IP update mechanisme. Things I have seen are for instance where the device will react on a specific size ping message to update its own IP address with whatever address that ping contains. This may seem a bit useless since you usually simply specify the IP address in the ping command. But this works in such a way that you first manipulate the local arp table in your computer. You can do that with the arp command line program (or calling into low level Windows network APIs, but this solution is very cumbersome).

First you make sure to delete any reference to the desired MAC address from the arp tables. Then you add a new arp entry with the specific MAC address and the desired IP address. When you now issue the ping command to that IP address (using the data packet load size your device is setup to recognize as the magic change my IP command), the device receives that ping packet and changes its internal IP address to whatever IP address the IP header of the ping packet contains.

This obviously will only work in the local subnet since the arp tables are not used when contacting a device in a different subnet but instead that request is passed on to the subnet gateaway.

Another theoretical solution would be maybe the use of InARP which is the Inverse ARP protocol. How to set that up and make it work I do however not know.

Rolf Kalbermatter

[ShaunR]

I test the network functionality of the embedded firmware for the various bar code and labeling printers my company makes. As for asking the admin for an IP address I am the admin and I manage a test network with 25 VLANs, multiple switches, multiple wireless access points and every possible WiFi security. When testing network securities every security is assigned to its own VLAN (subnet) and when testing securities you are not guaranteed the same address each time you test a given printer. We have too many devices to statically assign all the addresses. In addition, the major problem that we have is that individual printers can run different types of firmware. When a printer is switched from one type of firmware (generally a different printer control language) to another its network settings are defaulted and which can mean it switches in normal network security to the default of no security resulting in a new IP address. I am trying to write an utility that would scrub the network for these printers that changed and reconfigure them to their properly assigned network security. These printers are part of a lab that runs long term network stability tests. Manually reconfiguring every printer is very time consuming and a pain in the butt.

Since I am the admin I am actually looking at the possibility of querying the network switches for this information. I was hoping to avoid this if possible. However that is the path that I am currently investigating.

Side note: The printers do support a broadcast query to identify themselves on the network however there are issues with having this work reliably across subnets, at least when doing the query as a broadcast. Broadcast UDP traffic is not routed across subnets.

Hmmmm. Knarley one. Surprised there's no DNS in that lot though. It'd be easy then.

Personally I would try and get a change in the next firmware update (dip switch or special dongle) that means it remembers its last set IP address regardless of re-flashing (if set) or defaults (if not set). Then its not your problem...lol. We do it with things like baud rates and startup modes. Design for test is the motto. You can set it up on the bench and then put it where you like and forget about it.

But I'm guessing thats not an option (I'm very lucky in having very flexible engineers and managers that I can bully ). So I'll have a sleep on it and see if I can think of anything else.

[Mark Yedinak]

What sort of DHCP/BOOTP server do you run?

I tried (A LONG TIME AGO) to write a simple DHCP server in LabVIEW. I can't find the code now

I recall that some DHCP servers maintain a disk version of the lease table. After a few Google searches I found the name of the file was dhcpd.leases

The DHCP/BOOTP server on the network is a Windows 2003 server. It doesn't provide easy access to its address lease tables.

It would seem you have run into a big problem here. The only instance that knows about the IP address mapping of a dynamically assigned IP adress is the DHCP server that issued that address. The way this is usually solved is, that the specific client is known under a DNS name that it provides to the DHCP server when asking for an IP address. The DHCP server then will inform the DNS server about this new address.

I can't rely on DNS since the server can't update DNS tables when BOOTP is used. Our printer's (actually the print server's) default setting is to come up and attempt to obtain its address using any one of the following methods: DHCP, BOOTP, RARP (yes, ancient and obsolete technology), or a method we call GLEANING (which is effectively the ping method you suggested below). It will generally get the BOOTP address first, hence the probelm with the DNS lookup.

1) adding some address recovery support to the devices yourself.

Basically this would be some UDP broadcast message that your devices reacts too. The device will expect a specifically formatted packet on a well defined port. The package could contain a specific MAC address or a place holder to let all devices that receive it respond with a packet that contains the MAC address and the current IP address. This is obviously something most device manufacturers do not make public but since you are to test devices that your company manufacturers this should not be the problem.

Since UDP braodcasts are usually not routed, you can get in trouble with this in a setup with multiple IP subnets and would need to use TCP instead but that does not have an universal broadcast mechanisme like UDP.

As you noted, the multiple subnets is an issue with this approach. BTW, our printers already support a specific discovery message on a UDP port.

2) Another solution is to simply add some remote IP update mechanisme. Things I have seen are for instance where the device will react on a specific size ping message to update its own IP address with whatever address that ping contains. This may seem a bit useless since you usually simply specify the IP address in the ping command. But this works in such a way that you first manipulate the local arp table in your computer. You can do that with the arp command line program (or calling into low level Windows network APIs, but this solution is very cumbersome).

First you make sure to delete any reference to the desired MAC address from the arp tables. Then you add a new arp entry with the specific MAC address and the desired IP address. When you now issue the ping command to that IP address (using the data packet load size your device is setup to recognize as the magic change my IP command), the device receives that ping packet and changes its internal IP address to whatever IP address the IP header of the ping packet contains.

This obviously will only work in the local subnet since the arp tables are not used when contacting a device in a different subnet but instead that request is passed on to the subnet gateaway.

Again, the multiple subnet problem is an issue. In addition, I would have to worry about address contention using this approach. I doubt I can reserve the number of addresses needed to support this on the subnet. This is one of the most active subnets on the test network.

Another theoretical solution would be maybe the use of InARP which is the Inverse ARP protocol. How to set that up and make it work I do however not know.

Rolf Kalbermatter

I have been searching for such a protocol. I haven't found it yet. It would be nice if it worked though.

[Phillip Brooks]

The DHCP/BOOTP server on the network is a Windows 2003 server. It doesn't provide easy access to its address lease tables.

Would this help?

DHCP Server Callout API usage

Microsoft DHCP Server Callout API provides a way for developers to access thecritical phases of DHCP protocol processing in Windows Server 2003 family and later. This enables developers to:

Create customized extensions to the Microsoft DHCP Server

Monitor statistics

Create parallel lease databases

Provide other customized solutions

Edited September 11, 2009 by Phillip Brooks

[Mark Yedinak]

This certainly isn't a universal solution but I will be able to get the information I need from my switches/routers. I can get the information via SNMP.

Thanks for all of the suggestions though.