Hello,
We are using RL-RTX and RL-TCPnet and having a difficult time on some of our units getting assigned addresses from the DHCP Server. Ideally the DHCP Server would test the address before offering it but there is no requirement to do so and evidently ours has that feature disabled. The other side of the ideal situation is for the client to test the address with an ARP and if a response is received send back a decline message to tell the DHCP Server to allocate a different IP address. Unless I am missing something, there is no mechanism within RL-TCPnet to implement testing an offered address prior to sending the Request message. I also see no way to initiate sending a DHCP Release message to release an IP address. Is this functionality present in RL-TCPnet or is there another way around it? The DHCP server here remembers which MAC addresses were previously assigned IP addresses and keep sending the same address over and over. We have no local control over the DHCP Server.
Because the server assumes it's valid because it's within it's assigned range. It also knows that this MAC address was successfully assigned this certain IP address previously and offers it up again. The server has no way of knowing that some bozo statically assigned an address from the assigned range to a new device on the net. I'm not a network guru and I'm guessing the IT people have that functionality disabled for a reason. I plan on having the IT guys look into it but I'm having a hard time releasing a new product without the ability to compensate for something as simple as this.
Why does your product need to compensate for other network devices failing to honour their contracts with the server? Or a server issuing the same IP to different MACs within the contract term?
Have your device follow the rules. If I have a problem with it, or a default assigned static IP address (people make inconsistent choices about subnets things should be on), then I'll hook up your device to a safe walled garden router which doesn't have broken devices on it, and reconfigure it there.
Having your device trying to second guess what's happening on a network will make it one of the offending broken devices, don't do it.
It's IT's responsibility to make the network compliant, whether that's fixing their DHCP server(s) and their ranges, or finding broken devices.
Because the ability to do so is built into the DHCP interface. I prefer to do what ever I can to help my company release quality, user friendly instruments. If I can figure out a way to do it, I will. I see no gain in pointing fingers and blaming others, even if the root problem is someone else's issue.