sidcha
commented
1 month ago When the CP resends the command, it’s not waiting for a response to the previous command. It’s just trying to decide if the PD status must be marked as “offline”. The specification says the PD must respond to a given command within 200ms. But a PD can be marked as offline/unresponsive only after 8 seconds. So this grace period is not for PDs that failed to respond within 200ms.
Also, if a PD misses this 200ms SLA, it should not be silently ignored (will be the case if we don’t increment the sequence number).
Describe the bug ACU (CP Mode) should not increment the sequence number while requesting for the repeat of the last reply.
Expected behavior The ACU acknowledges the last reply by sending the next command with the incremented sequence number, or it repeats the command without changing the sequence number to request the repeat of the last reply
Observed behavior ACU (In CP mode), sequence number gets incremented while it is requesting for the repeat of the last reply. This behavior is observed for POLL command as well as any other command such osdp_CCRYPT.
In a case where PD replied with osdp_ACK(with sqn:2) for a osdp_POLL(for sqn:2) after 200 milisec (Lets say after 2145 milisec in above case), CP already had incremented the sqn number(sqn:3), which in turn results to a sqn mismatch as per library implementation and enters in to the error state for 300 1000 milisec. CP should send the same sequence number for at least 8 retries (8 (200 + 800) = 8000 milisec) as per default configuration in osdp_config.h.in.
Issue is observed in both Secure and Non-Secure operational mode.
Additional context I am using the library to build a comprehensive GUI based CP application that comply with OSDP specifications.