Steve Etter
Lifetime Supporting Member + Moderator
Ran into a new problem today that I thought I would share. It seems some updates to Windows, Java, and/or possibly AB software are preventing us the ability to disable BOOTP/DHCP in our 1792ES Safety Modules. The only solution I have been able to find is to break out an old laptop with old software and use it instead of my normal one.
I am running Win7 Enterprise, SP1, 64-bit. Java is 8. RSLinx Classic is 4.00.01. BootP DHCP Tool is 3.02.00. This same problem has shown to exist on our new Win10 laptops with fully updated software, too.
Using BootP, I am able to successfully set the IP address in the module and I can see it with RSLinx, but none of the three methods for telling it to disable DHCP are successful. I get a message back telling me the command is rejected. Similarly, when attempting to change the module properties in RSLinx, I get a similar error message. Finally, when attempting to use the built-in web page, I get a rejection notice from Java that each and every page is blocked because Java "can not verify self-signed Deployment Rule Set jar".
I've tried all of the Java security bypasses and the suggestions from ABs knowledgebase, but as I said, the only way I've been able to get past this is to use an old laptop with old software.
Just wanted to share this.
I am running Win7 Enterprise, SP1, 64-bit. Java is 8. RSLinx Classic is 4.00.01. BootP DHCP Tool is 3.02.00. This same problem has shown to exist on our new Win10 laptops with fully updated software, too.
Using BootP, I am able to successfully set the IP address in the module and I can see it with RSLinx, but none of the three methods for telling it to disable DHCP are successful. I get a message back telling me the command is rejected. Similarly, when attempting to change the module properties in RSLinx, I get a similar error message. Finally, when attempting to use the built-in web page, I get a rejection notice from Java that each and every page is blocked because Java "can not verify self-signed Deployment Rule Set jar".
I've tried all of the Java security bypasses and the suggestions from ABs knowledgebase, but as I said, the only way I've been able to get past this is to use an old laptop with old software.
Just wanted to share this.