-
-
Notifications
You must be signed in to change notification settings - Fork 77
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
Comments
What makes you think so? Can you cite the specification please.
Not sure what you mean by "real" card reader here.. I thought they were all real :) |
|
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. |
I agree. Thank you! |
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
The text was updated successfully, but these errors were encountered: