Enable the host application to force the firmware to behave like an identity reset when the firmware is reconfigured.

Use case:

The host application is a CIP Safety application the has to disable the standard Identity reset service and instead implements a safety specific reset service through the Safety Supervisor Object. This Safety Supervisor Object is registered at the firmware during the configuration phase and accepts a reset service from the network indicated to the host application with a CL3_SERVICE_IND. The host application now re-configures the firmware and basically expects the firmware to behave like during a standard Identity Reset.

Today, the firmware will not force a re-configuration of the physical and logical link in order to not interrupt any other protocols based on Ethernet and UDP/TCP that might run in parallel to EtherNet/IP on the netx.

However, in this specific case, from the network perspective, the reset service received through the Supervisor object shall behave just like the Identity Reset service.

With this ticket, the following actions need to be performed:

Define a mechanism for the packet API to control the flag CIPHIL_TCP_CMD_FORCE_NETIF_RESET_ON_NEXT_RECONFIG with regards to the behavior of subsequent stack re-configuration.
Do this for the release branch and the trunk.

Proposal:
Move the existing service CIPHIL_TCP_CMD_FORCE_NETIF_RESET_ON_NEXT_RECONFIG (0xF505) to a standard 8-Bit CIP service code 0x32 (vendor specific range).
This directly gives the host application access to this service.

The service 0x32 shall be supported through the host interface only. On the network side the service shall be rejected with "Service not supported" (0x08).

Related actions:

• Describe new API in API manual (hotfix and trunk)
• Python Test: Write new test that makes use of CIPHIL_TCP_CMD_FORCE_NETIF_RESET_ON_NEXT_RECONFIG