Description
So, very close to the top of bugs in Rockwell's ENIP stack on older cards that drives me crazy is the 1756-ENET not correctly responding to a broadcast identity request.
What it does respond with is status 0x01 for service not supported. The correct thing to do at this point is to send an explicit CIP message to request its identity.
The current CIPDriver.broadcast method ignores ENET modules since they do not reply with
4F6D
a status of 0x00 and a valid identity CPF item. One of two things could be done here to support the ENET. First, the broadcast could simply have a way to return a list of unknown devices that responded, but not with a valid response. Or second, it could try a CIP identity request if the broadcast ENIP identity request returns a status of 0x01
Personally I opt for the first option as it is less invasive and has better backwards compatibility. A way to implement it without breaking compatibility would be to pass it an empty list (as an optional argument) of unknown devices that it could populate with ip addresses. The list would only contain the addresses of unknown devices. Another implementation option would be to simply add to the resulting list of devices an object (UnknownIdentity perhaps) that only contains the information known about the device, such as {'encap_protocol_version': 1, 'ip_address': '192.168.1.12'}
Thoughts?
Thanks,
Trevor Flynn