Hi Dave
> After looking through the winscard portion of pcsc-lite I realized that I
> was just passing a suggested return size to the IFD_HANDLER. When the
> Transmit function returns in the IFD_HANDLER PC/SC actually returns back to
> the application whatever receive length that the IFD_HANDLER gets from the
> card. So, it if there are issues in 4 byte commands or Case 4 commands
> this is probably in the IFD_HANDLER for a particular driver.
>
> My guess is that if there are problems with Case 4 APDU's then it is
> probably that the IFD HANDLER is using the suggested receive size from pcsc
> instead of calculating it's own return length. So the way it should work
> is that the IFD Handler should be adding the extra 0x00 on Case 1 commands
> for T=0 and it should be handling the Case 4 commands. I won't have to
> make any changes to pcsc-lite since it just passes a suggested length to
> receive but then uses whatever is received from the IFD HANDLER.
I'm not sure, if this is the best way. The buffer for the response from the
card is allocated by the application. It should be common practice, that the
IFD HANDLER does never return more then the number of bytes specified in the
variable pointed to by pcbRecvLength. Otherwise the application may experience
a buffer overrun with unexpected results. Unfortunately PC/SC only specifies
"the data buffer for the returned data must be adequate to hold the maximum
amount of data that may be returned". I would not consider this a safe design.
Any comments.
--
Andreas Schwier Tel. +49 171 8334920
CardContact Software & System Consulting
http://www.cardcontact.de
***************************************************************
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***************************************************************
