Hi!

>>>> I think that a flag could be invented for switching between these
>>>> two modes of operation (the otherwise unused "flags" parameter to
>>>> sc_read_binary).  The default could be the mode that honors passed
>>>> in parameters.
>>> Actually the 0x6282 is mapped to the general SC_ERROR_CARD_CMD_FAILED
>>> error.
>>> http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/iso7816.c?rev=5237#L35
>>>
>>> Possible resolution could be:
>>>
>>> A new code error is introduced for the SW 0x6282 .
>>> The 6282 error is ignored if it's returned by the 'embedded'
>>> iso7816_read_binary .
>>> http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/iso7816.c?rev=5237#L137
>> Line 138 very well tests the return code. BUT sc_check_sw is not called
>> unless the number of bytes to be read is 0 (line 132, 133). So the
>> iso7816_read_binary almost never recognizes errors which are
>> communicated via the status bytes. So an other solution could be to
>> always check the status bytes (not only for apdu.resplen == 0).
>
> You have a reason,
> and I guess that 6282 SW is never returned with resplen=0.

Well, "never" is a bit strict. It depends on the card of course.

> Solution could be like in attached diff.
> Sorry, I have no appropriate card to test.

Your patch works for me. But I am not sure if exclusively checking for
6282 and ignoring the other error codes of the status bytes is
appropriate. Why are these ignored at all, has it something to do with
the retransmission as you stated in the commit message of r5237?

Cheers, Frank.

Attachment: pgpj6GMusxd6P.pgp
Description: PGP signature

_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to