Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of CMD_ID, CMD_CAP #210

Closed
AlexNCoder opened this issue Dec 26, 2024 · 4 comments
Closed

Handling of CMD_ID, CMD_CAP #210

AlexNCoder opened this issue Dec 26, 2024 · 4 comments

Comments

@AlexNCoder
Copy link

AlexNCoder commented Dec 26, 2024

Handling of CMD_ID, CMD_CAP

Hello everyone! I found that CMD_ID handling on PD is insufficient, maybe (func pd_decode_command, case CMD_ID). It sets ret to OSDP_PD_ERR_GENERIC when osdp-message from the CP (physical device, not libosdp) can be without data-bytes. By the way, real card reader (physical device) can handle such messages. Am I wrong?

Maybe we can change that condition from “if (len != CMD_ID_DATA_LEN)” to “if (len > CMD_ID_DATA_LEN)”
It's all the same about CMD_CAP ?

I've created a pull request

@sidcha
Copy link
Member

sidcha commented Jan 9, 2025

[..] when osdp-message from the CP (physical device, not libosdp) can be without data-bytes.

What makes you think so? Can you cite the specification please.

By the way, real card reader (physical device) can handle such messages.

Not sure what you mean by "real" card reader here.. I thought they were all real :)

@AlexNCoder
Copy link
Author

  1. Unfortunately, I haven’t specification of the devices (access control system STR20-IP, https://products.rubezh.ru/products/kontroller_str20_ip-3459/#download, CardReader RELVEST LTD PR-P03.M). I only have the user manual, in Russian(. But I had sniffed a traffic between osdp-devices. I’ll attach a small dump later. Maybe that devices deviate from OSDP standart?

  2. I work with an OSDP system of one card reader, one control system module and an computer-emulated osdp-device (by libosdp).
    Real, I meant which is not emulated :)

@sidcha
Copy link
Member

sidcha commented Jan 22, 2025

OSDP specification, section 6.4 (osdp_ID) and 6.5 (osdp_CAP) both have one data byte set to zero which requests the PD to send the "Standard Response". This is probably a future extension possibility that SIA included so the CP can ask the PD for some non-"Standard Responses" if needed.

The way I see it, any CP not including this byte (and PDs that expect it to be empty) have to be considered non-compliant. Please report this to the manufacturer.

@AlexNCoder
Copy link
Author

I agree. Thank you!

@sidcha sidcha closed this as completed Jan 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants