search

goToMain / libosdp

Implementation of IEC 60839-11-5 OSDP (Open Supervised Device Protocol); provides a C library with support for C++, Rust and Python3
https://libosdp.sidcha.dev
Apache License 2.0
134 stars 71 forks source link

Minimum answer length for RawCardData command #31

Closed z8a closed 3 years ago

sidcha commented 3 years ago

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?

sidcha commented 3 years ago

I found a bug in that area. Can you please check if that fixes your issue?

z8a commented 3 years ago

The problem happens when there is no event.

sidcha commented 3 years ago

Please describe your problem and the mode (CP or PD), the issue is not very clear to me yet.

z8a commented 3 years ago

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.

sidcha commented 3 years ago

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.

z8a commented 3 years ago

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'.

sidcha commented 3 years ago

According to specification, reply to a POLL can either be alternate replies (card read, key press or other events) or an ACK. Please check.

z8a commented 3 years ago

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".

sidcha commented 3 years ago

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?

sidcha commented 3 years ago

@z8a, Any updates on this?

z8a commented 3 years ago

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.

sidcha commented 3 years ago

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.

sidcha commented 3 years ago

Closing this issue due to inactivity. Please feel free to re-open if/when needed.