<div dir="ltr">In this case should this feature be configurable, at least? Say, on/off and/or making the "32" configurable?<br><br>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.<br>
<br>Thanks,<br>Ming<br><br><div class="gmail_quote">On Tue, Jul 29, 2008 at 1:14 AM, Sean Mullan <span dir="ltr"><<a href="mailto:Sean.Mullan@sun.com">Sean.Mullan@sun.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have asked someone who worked on this code and they said:<br>
<br>
I believe this is a failsafe to prevent the code from going into an<br>
infinite loop when talking to a bad card or driver.<br><font color="#888888">
<br>
--Sean</font><div><div></div><div class="Wj3C7c"><br>
<br>
Ming Yung wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 Hi there,<br>
<br>
This relates to a limitation (bug?) in the implementation of javax.smartcardio.Channel.<br>
<br>
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):<br>

<br>
 int k=0;<br>
 while (true) {<br>
    if (++k >=32) {<br>
      throw new CardException("Could not obtain response");<br>
    }<br>
     ....<br>
 Is there any reason for this condition? I cannot find it in ISO 7816-4 (2005 edition).<br>
<br>
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.<br>
<br>
Cheers,<br>
Ming<br>
<br>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>