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

Improper Handling of Response 6100 #84

Closed
flakjacket95 opened this issue May 7, 2018 · 2 comments
Closed

Improper Handling of Response 6100 #84

flakjacket95 opened this issue May 7, 2018 · 2 comments

Comments

@flakjacket95
Copy link

This issue arrises, in my case, when requesting a file greater than 256 bytes in size. I have executed a GET_DATA command, and the response sent back from the card is 6100

From my understanding, 6100 does not mean 0 bytes left to read, as your library seems to interpret it as. Instead, it means there are more than 256 bytes left, just read a full 256.

An example exchange would be as follows:

GET_DATA (00 CA/CB ...) --> Card
<-- 6100
GET-RESPONSE (00 C0 00 00 00) --> Card
<-- 6100
GET-RESPONSE (00 C0 00 00 00) --> Card
<-- 6143
GET RESPONSE (00 C0 00 00 43) --> Card
<-- 9000

Instead, your program sends the proper request but, appears to improperly setup the buffer, as I receive the following error:
Error: SCardTransmit error: Insufficient buffer.(0x80100008)

@santigimeno
Copy link
Owner

Can you post the sample code please?

@flakjacket95
Copy link
Author

flakjacket95 commented May 9, 2018

Yes, very simple really.

cmd = < Buffer 00 cb 3f ff 05 5c 03 5f c1 02 00>

and

cmd = < Buffer 00 c0 00 00 00>

My transmit code is as follows:

this.device.transmit(cmd, 0xFF, protocol, (err, response) => {
    ....
}

I think I've figured out what causes the issue. And that is that my interpretation of the 0xFF above was just including the response information and not the status code (sw1 and sw2). So, therefore, when 0xFF bytes of data are returned, the status code 6100 or whatever, actually makes the number of returned bytes 0x102. Hence, my issue can be resolved by increasing that number to 0x102

I'll close this issue now, as I think this is more an interpretation issue on my part but, perhaps a note in the docs could be helpful here, if anyone has this issue in the future.

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