Details
Description
According to the spec, for the SendUnitData encapsulation command, the sender context shall be chosen by the sender and ignored by the target. In a class 3 connection, we are bidirectonal, meaning both are senders and receivers.
When the scanner opens a class 3 connection and issues a request, we allocate a "service buffer" and encode its handle into the sender context field of the encap session. We expect the receiver to mirror that value back to us, so that we can map it back to the request, but this is formally incorrect for Cl3/SendUnitData, since the receiver is not obliged, not even encouraged, to mirror the value back whatsoever. For UCCM/SendRRData, the mechanism is fine.
We should rather use the T2O connection ID and the CIP Cl3 sequence number to map the CIP responses to the service buffers.