In this case should this feature be configurable, at least? Say, on/off
and/or making the "32" configurable?
The Exception message is extremely misleading, by the way. If it wasn't for
jpcsc I would have believed that the card did actually stop responding.
Thanks,
Ming
On Tue, Jul 29, 2008 at 1:14 AM, Sean Mullan <[EMAIL PROTECTED]> wrote:
> I have asked someone who worked on this code and they said:
>
> I believe this is a failsafe to prevent the code from going into an
> infinite loop when talking to a bad card or driver.
>
> --Sean
>
>
> Ming Yung wrote:
>
>> Hi there,
>>
>> This relates to a limitation (bug?) in the implementation of
>> javax.smartcardio.Channel.
>>
>> I am looking at doing APDU output chaining using the "SW 61XX and GET
>> RESPONSE" mechanism in order to transfer large datasets out of a JavaCard.
>> As it stands, I am limited to chains of length 31 because of the following
>> condition in sun.security.smartcardio.ChannelImpl.doTransmit(byte[]
>> command):
>>
>> int k=0;
>> while (true) {
>> if (++k >=32) {
>> throw new CardException("Could not obtain response");
>> }
>> ....
>> Is there any reason for this condition? I cannot find it in ISO 7816-4
>> (2005 edition).
>>
>> Right now, a workaround is to set the undocumented system property
>> "sun.security.smartcardio.t1GetResponse" to "false" (I'm using a T=1 card)
>> and handle the chaining outside smartcardio.
>>
>> Cheers,
>> Ming
>>
>>
>>
>>
>
