Need to Implement Reverse Address Resolution Protocol (RARP) Server in a Real-Time (RT) PXI System

[Nick014]

The Reverse Address Resolution Protocol (RARP) is used by a client in a network environment to dynamically acquire its Internet Protocol (IP) address. The client broadcasts an RARP request message for its IP address based on its MAC (Media Access Control) hardware address.

The RARP server must be configured to listen for RARP requests and generates a RARP reply message to the client.

Has anybody implemented an RARP Server in an RT PXI System or a regular LabVIEW environment? We are preferably looking for a PXI solution.

According to the NI support team all of the LabVIEW functions pertain to the IP layer of Ethernet communications. The RARP protocol is implemented below that in the link layer of the Ethernet frame, so we won't be able to implement a RARP server in LabVIEW.  They suggested to try to find a third-party RARP server and run it from LabVIEW using the system exec.vi or find a call library function node to do the same.

[Craig_]

How does this differ from DHCP?

[Craig_]

After searching I found this:

"RARP is described in Internet Engineering Task Force (IETF) publication RFC 903.[1] It has been rendered obsolete by the Bootstrap Protocol (BOOTP) and the modern Dynamic Host Configuration Protocol (DHCP), which both support a much greater feature set than RARP."

http://en.m.wikipedia.org/wiki/Reverse_Address_Resolution_Protocol

So I guess the question would be why do you need RARP when the systems already use DHCP? (I'm assuming this is some sort of legacy network?)

[Nick014]

The RARP client only supports the RARP protocol and not DHCP

[Craig_]

How old are these devices?

Here's a snippet from the BOOTP page:
"The BOOTP protocol was first defined in September 1985 in RFC 951 as a replacement for the Reverse Address Resolution Protocol RARP, published in RFC 903 in June 1984. The primary motivation for replacing RARP with BOOTP is that RARP was a link layer protocol. This made implementation difficult on many server platforms, and required that a server be present on each individual IP subnet. BOOTP introduced the innovation of a relay agents, which forwarded BOOTP packets from the local network using standard IP routing, so that one central BOOTP server could serve hosts on many subnets.[1]"

http://en.m.wikipedia.org/wiki/Bootstrap_Protocol

Considering RARP was so quickly replaced getting this to work on modern hardware won't be easy (as you already know).

[Nick014]

The hardware only supports RARP and requires an RARP response message containing the IP address for the client

[billko]

---

@Nick014 wrote:

The hardware only supports RARP and requires an RARP response message containing the IP address for the client

---

Unfortunately no matter how often you repeat it, it doesn't make it any easier to support.  😞

That's one issue about holding on to legacy hardware.  Eventually no one supports it.  This happens most often when a new OS comes out.  The company is dead, and none of the vultures companies have picked the bones and bought the rights to any of their products, so the old drivers don't work.

That being said, you can't use a static IP address?

[Nick014]

We can't use a static IP address since we need to support multiple units.

[billko]

---

@Nick014 wrote:

We can't use a static IP address since we need to support multiple units.

---

You can set each to a different static IP address and then reserve the addresses on your DHCP server.

[Nick014]

The client needs to see an RARP message in response with the its IP address. It does not support the DCHP protocol.