Pool packet of Object task might be returned into its source pool by Encapsulation task although it is still in use.

Pool packet of Object task might be returned into its source pool by Encapsulation task although it is still in use.

As soon as the Object task re-uses this packet for other jobs, conflicts can happen since now two tasks use the same packet for different things.

This bug was introduced when adding the capability to handle incoming class3 request messages that hold the same sequence count as the previous request message.

Probability of failure:
The issue shows up only in case CIP request messages are sent with a sequence count being the same as in the previous request message (info: this mechanism can be used to keep Class 3 connections alive and to deal with cases of dropped packets).
For instance Rockwell PLCs send messages with the same sequence count in case the PLC's application programm does not trigger CIP services fast enough. E.g. the RPI of the class3 connection is configured to be 1 second, but the PLC programm ony triggers CIP messages every 3 seconds. In that specific case the PLC will automatically send out CIP messages holding the previous sequence so that the RPI value is met and no connection timeout can occurr.

The probability of the error increases the more often CIP messages with a duplicate sequence count are handle by the stack. So if there is a scenario as describes above, the issue will definitelly show up after a couple of minutes.

Error scenario:
When the issue shows up, the first thing that can be observed is, that at some point an incoming CIP request message is not answered anymore by the stack and the class3 connection runs into a timeout. It is also possible that the firmware crashes afterwards.