Closed z8a closed 3 years ago
I found a bug in that area. Can you please check if that fixes your issue?
The problem happens when there is no event.
Please describe your problem and the mode (CP or PD), the issue is not very clear to me yet.
My device is a PD that is a 433MHz radio receiver. When it receives a radio command transmission it enqueues in the events. When the CP sends a osdp_RAW command the PD answers with the s/n and button code. The problem arises when the CP sends the command and there aren't events enqueued. At the moment the answer is an ACK but the CP wants 4 byte.
As per the specification osdp_RAW
is reply (not a command) that a PD can send in response to a osdp_POL
command. A poll command can also be replied with an osdp_ACK
reply if there is no alternate response (events) available to the PD.
If no events are there, the CP should be capable of accepting osdp_ACK
too as a periodic polling is needed to keep any established secure channel active.
Yes, you are right but looking at the standard the answer to POLL is not ACK but any of the reply messages marked as 'poll response'.
According to specification, reply to a POLL can either be alternate replies (card read, key press or other events) or an ACK. Please check.
I've release 2.1.6 of the standard and at point 3.1: 3.1 Poll (osdp_POLL) This command serves as a general inquiry. The PD may return any reply that is marked as a possible "poll response". Normally, the PD will return any unreported input data or status change information as a poll response. Command structure: None Reply: Any of the Reply messages marked "poll response".
Okay, I see where the confusion arises from. The reply osdp_ACK
is not explicitly marked as a "poll response". I think this is miss in the specification.
But please see, Section 3 Commands:
The PD shall return an osdp_ACK response if each command record was accepted by the PD, otherwise, the PD shall return an osdp_NAK reply
So technically, the osdp_POLL
command was accepted by the PD (no checksum/MAC/format errors), and there was no suitable "poll response" available at the time. Under this circumstances, the PD is free to reply with osdp_ACK
. On top of that, to maintain a Secure Channel, osdp_POLL
needs to be sent periodically to maintain the session and naturally the PD cannot have some event pending all the time. On top of that, from experience working with multiple commercially available OSDP devices, I can tell you this is how they work.
So, I think the CP is not compliant here. Can tell me more about your CP hardware? is it a productized already? how does it manage a secure channel if osdp_ACK
is not a valid response for osdp_POLL
?
@z8a, Any updates on this?
As I told you two libraries I'm using want a minimum of 4 byte in the answer. The access control system developed by our company seems to accept a shorter answer. The firmware developer is on holiday this week and then I'll ask him next week.
As I told you two libraries I'm using want a minimum of 4 byte in the answer.
Can you point me to those libraries? I'll try to talk with the authors.
Closing this issue due to inactivity. Please feel free to re-open if/when needed.
As per the spec, this command must have at least 4 bytes. I see that is what LibOSDP expects 4 bytes too. In which mode are you experiencing this issue?