Le 21/04/2011 10:55, Frank Morgner a écrit : > 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.
Afaiu, to return responlen=0 the offset has to be at the limit of the file size and this situation is a subject of 'invalid P1-P2' error. >> 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. It's open to be extended with the other 'warnings' that can be ignored, but ... > Why are these ignored at all, has it something to do with > the retransmission as you stated in the commit message of r5237? ... the other 'warnings' should not happen with 'READ BINARY' when data are returned, with exception of 6281 'Part of the returned data may be corrupted'. I guess that this 'warning' is an error and cannot be ignored. An appropriate checking has to be added to the proposed diff . > Cheers, Frank. Kind wishes, Viktor. > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
