I'm a Unix sysadmin at a company that uses many, many PLCs. So many that I'm assured that statically defining them is an impossibility.

These devices have run fine in the past assigned in BOOTP via MAC address running from Solaris DHCP servers.

Now that I'm migrating to a new DHCP server, I've run into an issue that prevents Modbus communications once the PLCs have been assigned an IP from the new DHCP server.

According to the PLC vendor, the PLC broadcasts 8 BOOTP requests upon startup. The first request is a 802.3 formatted BOOTP request. It's then followed by other requests including an Ethernet2 frametype formatted BOOTP request.

According to the vendor, whichever request is answered by the DHCP server (which of course is the first request) will determine frame type for the PLC. Since I'm answering 802.3 formatted requests on my new servers, The PLCs are assuming 802.3 frametype, which prevents Modbus communication and heartbeat.

I do not yet know why this "just works" on the old Solaris DHCP servers. They ignore the 802.3 requests and ony answer the ethernet2 formatted requests.

I've tried using DHCP\BOOTP RFC option 36 to assign frame type, but it's a no go.

I've sniffed all traffic and used wireshark to verify what's happening.

Can anyone provide any assistance to this poor systems guy overwhelmed with the difficulties I've experienced with these devices?

Thanks in advance,
Dave

 

What kind of PLC are you using? As a reality check, you might try obtaining your address from other sources. For example a home router, windows DHCP server, or even a BOOTP server app. These different DHCP servers might vary in how they respond to BOOTP requests (DHCP is an extension of BOOTP, for others new to the thread). RFC 36 (ethernet) does sound correct. Any guess on what the problem is with Modbus? I don't know much about how Modbus TCP works.

----
Nathan Boeger
http://www.inductiveautomation.com

 

Is there any chance that iptables or something else (whatever filtering Solaris uses) was being used to filter out the 802.3 requests? If the DHCP server doesn't see the requests, it won't answer them.

From your description, it sounds as if the PLC isn't using DHCP properly, but there isn't anything you can do about that. So far as I know, option 36 (option ieee802-3-encapsulation) tells the client what it is supposed to use. If the PLC won't use that information, then you have to somehow ignore the 802.3 requests from it.