Details
Description
It is expected (and protocol stack relies on it) that a PNS_IF_CHECK_IND is answered as PNS_IF_CHECK_RES within the exact same packet pointer.
In case an application uses a different packet pointer to return a valid PNS_IF_CHECK_RES this is not detected by protocol stack. However the protocol stack gets stuck in CheckIndication handling and communication can not be established.
This scenario is almost impossible to detect drom the outside and even inside the protocol stack a deep look is required to find out what causes the unexpected issue in CheckIndication handling.
It is expected that protocol stack generates a user error indication if it detects a wrong packet pointer when handling PNS_IF_CHECK_RES.