This proposed change is to add detection and handling by the CP of a busy reply from a PD where the busy reply was sent with sequence number 0, as per the OSDP specification. Otherwise the busy reply would be rejected as having a "packet seq mismatch".
Also, the building of the osdp_CHLNG(0x76) command is modified to not perform the generation of random numbers each time the message is sent (or re-sent). Instead the random number generation is moved to osdp_sc_init(). Otherwise new random numbers could cause the challenge response to be rejected due to the PD possibly using the random numbers from a previously sent osdp_CHLNG command when it replied busy.
Previously the following timeout was used for both retrying commands and retrying to establish communications:
Note that the default online retry timeout is significantly reduced to 1 second. The short timeout allows quickly retrying establishing the connection and often quickly succeeding. It's not known if there may be situations where this shorter timeout may be an issue.
The motivation for these changes came from working with a particular badge reader when it was configured for baud rates of 38400 and higher. At the higher baud rates, the badge reader would often reply with an osdp_BUSY(0x79) to an osdp_CHLNG(0x76). The following log snippet (where the first number on each line is a relative time stamp in seconds) shows the issue for one of the worst cases where it took a long time to recover:
This proposed change is to add detection and handling by the CP of a busy reply from a PD where the busy reply was sent with sequence number 0, as per the OSDP specification. Otherwise the busy reply would be rejected as having a "packet seq mismatch".
Also, the building of the osdp_CHLNG(0x76) command is modified to not perform the generation of random numbers each time the message is sent (or re-sent). Instead the random number generation is moved to osdp_sc_init(). Otherwise new random numbers could cause the challenge response to be rejected due to the PD possibly using the random numbers from a previously sent osdp_CHLNG command when it replied busy.
Previously the following timeout was used for both retrying commands and retrying to establish communications:
Two timeouts are now defined:
Note that the default online retry timeout is significantly reduced to 1 second. The short timeout allows quickly retrying establishing the connection and often quickly succeeding. It's not known if there may be situations where this shorter timeout may be an issue.
The motivation for these changes came from working with a particular badge reader when it was configured for baud rates of 38400 and higher. At the higher baud rates, the badge reader would often reply with an osdp_BUSY(0x79) to an osdp_CHLNG(0x76). The following log snippet (where the first number on each line is a relative time stamp in seconds) shows the issue for one of the worst cases where it took a long time to recover:
Following are the send/receive messages for when the first busy reply occurred:
The following log snippet shows the behavior with the improved busy reply handling:
The following is a portion of the preceding log snippet with the send/receive messages included: