Security Class 1 feature to reject DCP when AR is established is not working as expected

The Profinet protocol stack supports Profinet Security Class 1. However, this feature explicitly needs to be enabled by the user. One of the features of Security Class 1 is the "DCPReject-Feature" which simply rejects DCP Set operations in case an AR exists which activates the feature.

The following issues exist in Profinet protocol stack regarding this SecurityClass 1 DCPReject feature:

• An AR using DCPReject feature is not rejected in case SecurityClass 1 is not enabled in protocol stack
  • It is expected that the AR itself is not established in this case. The ConnectRequest shall be rejected stating "invalid ARProperties".
• An AR using DCPReject feature is accepted but feature is silently not working in case SecurityClass 1 is enabled in protocol stack
  • it is expected that a DCP Set is rejected if AR is established

The Profinet specification changed between V2.4 MaintenanceUpdate 2 and MaintenanceUpdate 3 regarding this specific DCPReject feature. Older versions of specification (MaintenanceUpdate 2 and older) used a different bit to enable the DCPReject-Feature. IO Controller following the newer versions of the specification (to which this implementation claims support), will use the new bit which is simply ignored by the Profinet protocol stack as he is only checking the old bit.

Hilscher Profinet Protocol stack implementation was done some time ago based on specification V2.4 MaintenanceUpdate 2.

As there are no known IO Controller implementation in the market supporting this feature, we missed to change our implementation after modified specification was released. With experimental support of this feature in certification tool, this issue is uncovered.