Hi Ming,
Ming Yung wrote:
In this case should this feature be configurable, at least? Say, on/off
and/or making the "32" configurable?
Yes, probably.
Could you file an RFE at bugs.sun.com? Please use the JDK/JRE category
and the classes_security subcategory.
Thanks,
Sean
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]
<mailto:[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