1756-ENET broadcast support

[tlf30]

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 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

[ottowayi]

That is interesting and not at all surprising. But either method seems alright with me, I think requesting the CIP identity would be the most helpful from a user perspective. I'd imagine anyone getting identity-less discovery results would end up doing it themselves manually anyway, so doing it automatically is probably the way to go. But, could also add an arg in the discover method to enable/disable it and if disabled, just return without any identity info.