OSM-1000-BRD as PD gets packet seq mismatch

[nathanabrewer]

PACKET: FF 53 80 14 00 04 45 CA 44 6C 01 00 C7 92 02 00 01 07 0F C4 42 PACKET: FF 53 80 23 00 05 46 01 01 02 02 01 01 03 01 00 04 02 01 08 01 00 09 01 01 0A 00 02 0D 00 01 10 01 00 D9 08 PACKET: FF 53 80 09 00 06 41 06 A0 BA OSDP: ERROR: PD[0]: PD replied with NAK(6) for command 76 OSDP: ERROR: PD[0]: CHLNG failed. Online without SC PACKET: FF 53 80 09 00 06 41 06 A0 BA OSDP: ERROR: PD[0]: PHY: packet seq mismatch 3/2

Adding pd->seq_number = -1; to the referenced section below fixes this for me, however I am looking for a proper fix.

https://github.com/goToMain/libosdp/blob/569e4c7c0364745f71a23df0c23da350288e4de2/src/osdp_cp.c#L937-L941

[sidcha]

@nathanabrewer, Can you pastebin the logs when you build the CP with cmake -DCONFIG_OSDP_PACKET_TRACE=on and log level set to LOG_DEBUG? The logs you have provided is not enough to analyse this issue.

[bytedreamer]

@nathanabrewer I've seen the OSM-1000 randomly go offline with my OSDP.Net lib. If the sequence number is not set to -1, does it go offline with libosdp?

[sidcha]

@nathanabrewer I've seen the OSM-1000 randomly go offline with my OSDP.Net lib. If the sequence number is not set to -1, does it go offline with libosdp?

If there is a sequence mismatch, then libosdp would go offline. If more verbose logs are made available, I can look into it.

@nathanabrewer, ping?

[bytedreamer]

I think that it has been resolved on OSDP.Net lib by restarting the device connection sequence when the reader goes offline.

[sidcha]

I think that it has been resolved on OSDP.Net lib by restarting the device connection sequence when the reader goes offline.

I think this happens by default in LibOSDP. The section referenced above is when CP challenge fails. In this case, IMO, there should not be any need to reset sequence number (although resetting it there won't hurt) as the PD hasn't gone out of communication yet.

For now, I'm inclined to fixing this by just calling phy_reset().

[bytedreamer]

@cbsiddharth Added similar logic to handle security init issues. After a few iterations, this worked well for handling from the CP side.

if (reply.IsSecureMessage)
{
    var mac = device.GenerateMac(reply.MessageForMacGeneration.ToArray(), false);
    if (!reply.IsValidMac(mac))
    {
        ResetSecurity(device);
        return;
    }
}

and

if (reply.Type == ReplyType.Nak &&
    (reply.ExtractReplyData.First() == (byte) ErrorCode.DoesNotSupportSecurityBlock ||
    reply.ExtractReplyData.First() == (byte) ErrorCode.CommunicationSecurityNotMet))
{
        if (reply.Sequence > 0) ResetSecurity(device);
}

The ResetSecurity method basically resets the connections as if a new device has been added.