# Problem during usage of BOOTP/DHCP server software



## Signode

Hi;

To assign an IP to a device, I have installed BOOTP/DHCP server (by Rockwell). By following the instructions, I send IP to a connected device upon its MAC. When I click “Disable BOOTP/DHCP”, after some time, every time message appears “Failed to complete the requested operation……………” and in status bar, “Socket connect failed………..”. All the connections are ok that’s why the MAC address of device appears in BOOTP. I do also set the same series IP and Subnet Mask of Laptop (say 172.16.28.250 and 255.255.255.0) as that which I want to set to device (say 172.16.28.255 and 255.255.255.0). Don’t know why I am facing the problem. Kindly help me out.


----------



## Rora

Hard to understand what you mean... does the BOOTP assign the address successfully? Why are you disabling it? Dynamically assigned addresses have an expiration, after which they'll attempt to renew the lease. If that fails, some devices keep using the same IP, others will not.

Also, not sure if you used the IPs from your example, but 172.16.28.255/24 is a broadcast address for the 172.16.28.0 network, it can't be assigned to a host.

What is the network topology here, are you directly connected, through a switch, through router(s)?


----------



## Signode

Rora said:


> Hard to understand what you mean... does the BOOTP assign the address successfully? Why are you disabling it? Dynamically assigned addresses have an expiration, after which they'll attempt to renew the lease. If that fails, some devices keep using the same IP, others will not.
> 
> Also, not sure if you used the IPs from your example, but 172.16.28.255/24 is a broadcast address for the 172.16.28.0 network, it can't be assigned to a host.
> 
> What is the network topology here, are you directly connected, through a switch, through router(s)?


Kindly google "How to use BOOTP/DHCP server" as i am unable to give a link here because of less than 20posts, in these instructions which i am following, it is mentioned that after assigning IP address to a device, click on the IP address in relation list and click on button Disable BOOTP.
The IP address which i did mention is just for an example. All the systems have the IP addresses such as 172.16.28... 
We have connected with a company network via an Ethernet switch. The device (here is a PLC) is also connected with same Ethernet switch and it dont have IP address. Via BOOTP, i assign IP address successfully but upon cycle the power of PLC, it losses the IP. To prevent this, we have to follow the above mentioned procedure (click on disable BOOTP button) but every time i received failed message.


----------



## MDShunk

Yes, the last step when assigning a static IP with BOOTP is to disable. That's what saves the IP address to the device permanently, as you found out. 

Allen-Bradley stuff is ripe with bugs. Always has been. You'll get a kick out of the "fix" from the KnowledgeBase article on that error:

_19. If the following error happens, wait one minute, click the OK button and try to disable the BOOTP-DHCP again. Repeat this action until the BOOTP-DHCP is disabled. This is very important!_


----------



## paulengr

First off you should NIT use .255 as the final octet because that means something to the Ethernet switches (broadcast). Also 0 is often special. Stick with 1-254. Most PLC networks use say 1-99 as static IPs and 101-254 as dynamic. I also prefer to set all technician laptops in 201-254 sequentially and different so if we both plug in we don’t cause conflicts and get booted off the network. Regardless of whether you use 192, 168, 172, or 10 nonroutable addresses. I prefer to group each PLC and it’s I/O on say every 10 and put routers, servers, and similar devices on the first 9 so those are 1-9 (and I reserve .1 fir the router), PLC 1 on 10, I/O on 11-19, PLC 2 on 20, I/O on 21-29, etc., then HMIs on 50-99, and so forth. Leave plenty of room for expansion since nonroutable IP addresses are “free”.

Allen Bradley BOOTP is both buggy and it’s very important to NOT have it plugged into your office network. When the device boots, it broadcasts the BOOTP request. Every DHCP server including the office Microsoft Windows one responds. By the time you type one in, it’s too late. Plus as mentioned this system is buggy.

Instead here’s option one. Let it go randomly wherever the office server sets it. Use Angry IP scanner to hunt it down. Angry is free and will show you both IPs and the manufacturer so it’s really easy to spot wayward hardware that wandered off into IT land. Connect and manually set it and turn BOOTP off from the software (RSLogix, etc.).

Option 2 use Option 81 relaying in the switch or the DHCP server in the switch so you control it. Option 3 get rid of ALL other DHCP/BOOTP servers on your network or set it in the shop. At $30 on Amazon for a small managed switch for troubleshooting purposes cost is simply not a factor. I don’t use these switches for production but with a cheap 3-4 port switch you can insert it between the PLC and say switch, plug both ports of your laptop into the switch (or swap with port 4), and set up port mirroring to say port 3, and run wire Shark to sniff the network. That is by the way how the high end AB and Cisco techs do it. Wireshark is intimidating but easy once you understand it and what it’s telling you.

Once you get ANY address programmed go in and set it and turn off BOOTP from the RSLogix or web server software. BOOTP just isn’t reliable enough for this.

I also highly recommend putting the controls on a separate network or at least a virtual one and I can’t stress this enough. I can’t tell you how many times IT people crash control systems because they are dumb as rocks and think 24/7 uptime ends at 5 PM and that nobody will notice when they reconfigure the network at any time of the day or night and take down your control system.

Also suggest staying away from IT garbage hardware. You can identify it easily because the label will say either Cisco or Allen Bradley (rebranded Cisco) on it. Among other problems three big issues are no real flow control...accounting at the end of the month can do a huge download of spreadsheets and since no matter what they claim Cisco does not implement throttling (I can’t assign say min/max bandwidth per VLAN or per port), their 200,000+ packets per second means your controls network at 100 packets per second can’t communicate and crashes when 2-3 packets are lost. Second problem is IOS (Cisco not Apple) is worse than any PV. I’ve clocked it at 45-50 minutes rebooting on power failure. Want your production line down that long or troubleshooting controls when it’s really bad network hardware? Third issue: the port lockout feature or I mean bug. If your hardware gets damaged in any way (and whoever heard of that in an industrial environment?) the Cisco switch unlike real hardware can’t deal with hardware errors. So the thoughtful Cisco engineers instead disable the port including cutting power to it so it looks “dead”. You have to have administrative rights on the switch to revive it (40-45 minutes later...). Imagine a technician trying to troubleshoot a defective cable when it got pulled out and the switch simply disabled the port.

Stick with real industrial switches...Hirschmann, Moxa, Sixnet, RuggedCom, N-Tron and bam IT garbage off high reliability controls networks.


Sent from my iPhone using Tapatalk


----------



## Rora

Signode said:


> Via BOOTP, i assign IP address successfully but upon cycle the power of PLC, it losses the IP. To prevent this, we have to follow the above mentioned procedure (click on disable BOOTP button) but every time i received failed message.


Alright, that makes sense... the disable BOOTP tells the to PLC retain the address it was given so it doesn't request a new one after power cycle.

Reason I ask about network topology is because the ports for BOOTP and DHCP might be allowed by a firewall device (we can assume this is true because the initial BOOTP request succeeds)... but packet(s) telling the PLC to disable it's BOOTP request upon startup may not be, since it may be proprietary to the PLC.

I would follow MDShunk's advice and follow the recommended procedure:



> 19. If the following error happens, wait one minute, click the OK button and try to disable the BOOTP-DHCP again. Repeat this action until the BOOTP-DHCP is disabled. This is very important!


Beyond that, I would look at network device active above layer 2 (IP--routing, port/socket--firewall), including firewall on the laptop... be sure antivirus software and Windows firewall is disabled.

As paulengr stated, the software is pretty buggy, so you may consider assigning the IP, disable BOOTP, etc. while directly connected to the PLC, if all else fails.

edit: article here suggests newer versions of the tool are buggy, and that you may try using the drop-down menu instead of the button, or even using an older version.

http://www.plctalk.net/qanda/showthread.php?t=110609


----------



## emtnut

paulengr said:


> First off you should NIT use .255 as the final octet because that means something to the Ethernet switches (broadcast). Also 0 is often special. Stick with 1-254. Most PLC networks use say 1-99 as static IPs and 101-254 as dynamic. I also prefer to set all technician laptops in 201-254 sequentially and different so if we both plug in we don’t cause conflicts and get booted off the network. Regardless of whether you use 192, 168, 172, or 10 nonroutable addresses. I prefer to group each PLC and it’s I/O on say every 10 and put routers, servers, and similar devices on the first 9 so those are 1-9 (and I reserve .1 fir the router), PLC 1 on 10, I/O on 11-19, PLC 2 on 20, I/O on 21-29, etc., then HMIs on 50-99, and so forth. Leave plenty of room for expansion since nonroutable IP addresses are “free”.
> 
> Allen Bradley BOOTP is both buggy and it’s very important to NOT have it plugged into your office network. When the device boots, it broadcasts the BOOTP request. Every DHCP server including the office Microsoft Windows one responds. By the time you type one in, it’s too late. Plus as mentioned this system is buggy.
> 
> Instead here’s option one. Let it go randomly wherever the office server sets it. Use Angry IP scanner to hunt it down. Angry is free and will show you both IPs and the manufacturer so it’s really easy to spot wayward hardware that wandered off into IT land. Connect and manually set it and turn BOOTP off from the software (RSLogix, etc.).
> 
> Option 2 use Option 81 relaying in the switch or the DHCP server in the switch so you control it. Option 3 get rid of ALL other DHCP/BOOTP servers on your network or set it in the shop. At $30 on Amazon for a small managed switch for troubleshooting purposes cost is simply not a factor. I don’t use these switches for production but with a cheap 3-4 port switch you can insert it between the PLC and say switch, plug both ports of your laptop into the switch (or swap with port 4), and set up port mirroring to say port 3, and run wire Shark to sniff the network. That is by the way how the high end AB and Cisco techs do it. Wireshark is intimidating but easy once you understand it and what it’s telling you.
> 
> Once you get ANY address programmed go in and set it and turn off BOOTP from the RSLogix or web server software. BOOTP just isn’t reliable enough for this.
> 
> I also highly recommend putting the controls on a separate network or at least a virtual one and I can’t stress this enough. I can’t tell you how many times IT people crash control systems because they are dumb as rocks and think 24/7 uptime ends at 5 PM and that nobody will notice when they reconfigure the network at any time of the day or night and take down your control system.
> 
> Also suggest staying away from IT garbage hardware. You can identify it easily because the label will say either Cisco or Allen Bradley (rebranded Cisco) on it. Among other problems three big issues are no real flow control...accounting at the end of the month can do a huge download of spreadsheets and since no matter what they claim Cisco does not implement throttling (I can’t assign say min/max bandwidth per VLAN or per port), their 200,000+ packets per second means your controls network at 100 packets per second can’t communicate and crashes when 2-3 packets are lost. Second problem is IOS (Cisco not Apple) is worse than any PV. I’ve clocked it at 45-50 minutes rebooting on power failure. Want your production line down that long or troubleshooting controls when it’s really bad network hardware? Third issue: the port lockout feature or I mean bug. If your hardware gets damaged in any way (and whoever heard of that in an industrial environment?) the Cisco switch unlike real hardware can’t deal with hardware errors. So the thoughtful Cisco engineers instead disable the port including cutting power to it so it looks “dead”. You have to have administrative rights on the switch to revive it (40-45 minutes later...). Imagine a technician trying to troubleshoot a defective cable when it got pulled out and the switch simply disabled the port.
> 
> Stick with real industrial switches...Hirschmann, Moxa, Sixnet, RuggedCom, N-Tron and bam IT garbage off high reliability controls networks.
> 
> 
> Sent from my iPhone using Tapatalk


Good advice Paul. I'd add that usually the router is either .1 or .254, so good numbers to steer clear of.
Some networks will have multiple routers using .1 to .10 range as well.
You also need to know the range for the DHCP server.
Bottom line, you need to know your network when playing with things !


----------

