4 Replies Latest reply: Jan 18, 2013 10:30 AM by fgrieu RSS

    PC/SC SCardTransmit 0x45D error


      i have a weird problem with my card or my card reader.
      First of all, my card and the reader works fine, i installed an applet and it works.

      But when i send an APDU to call a function on the applet which works longer then 800ms this error occur (PC/SC SCardTransmit 0x45D: unknown error code).

      When i manipulate my applet by commenting something in the function out (so that the runtime of the function is under 800ms) all works fine. So for me it seems that this is a timeout problem.

      Someone knows this problem ? Is the only way du solve the problem to split the longer functions into two or three functions ? For me, a timeout after 800ms is kind of weird.
        • 1. Re: PC/SC SCardTransmit 0x45D error
          Hana Bizhani

          would you please paste your code here?

          • 2. Re: PC/SC SCardTransmit 0x45D error

            What reader are you using? You may need to update the drivers or firmware. 800ms is quite low for a timeout.

            - Shane
            • 3. Re: PC/SC SCardTransmit 0x45D error
              0x45D is a pcsc error caused often by a slow apdu (usually something like a genkeypair), that causes a protocol drop.
              You can try to optimize the apdu on the card side and try to manage the connection protocol on the other side.
              Try also to change the connection parameters manually to detect if you can find a workaround.
              If you are lucky, you can solve just upgrading the reader drivers.
              • 4. Re: PC/SC SCardTransmit 0x45D error
                The symptom you describe would be typical of a non-conformance to the relevant communication protocol (ISO 7816-3 T=0, ISO 7816-3 T=1, ISO 14443-4...) of either the card or the reader. All these protocol have a mechanism which, when working, allows the card to ask for more time to perform its duties. Java Card platforms are supposed to do that negotiation in the background when necessary, and things often work for the best unless the reader/driver/PCSC has a bug. On the other hand I once met a Java Card runtime platform with broken implementation of that mechanism that would often stop working for no apparent reason; and another where this mechanism would not work during certain primitives, like RSA key generation.

                Still, I think there are ways an applet can make a well-behaved Java Card runtime platform break the communication protocol due to slow processing. In particular, due to a limitation of the ISO 7816-3 T=0 protocol, when not using block chaining, it is difficult to perform this negotiation for more processing time between segments of the outgoing data of the same R-APDU. Thus an applet using multiple sendBytes() during the same APDU, with a delay between them, is not unlikely to cause what you observe when the delay exceeds a certain time limit (and bound to do so unless the runtime makes either under-the-hood buffering, or use an highly unusual option of the T=0 protocol where there is an ACK byte equal to the complement of INS for each payload byte transfered). That time limit defaults to 9600*372/Fclk where Fclk is the clock frequency, often 3.5 to 5 MHz, and that makes the limit not far from 800 ms. I do not know if some Java Card runtime platforms have this failure mode for a delay between setOutgoing() and a single sendBytes(), but would not be too surprised if that was.

                AFAIK neither usual Java Card runtime platforms nor the ISO 7816-3 or ISO 14443-4 communication standards define a maximum overall delay for the card's APDU processing time. However some readers/driver/PCSC/utilities/applications do have such an overall timeout (sometime parameterized somewhere), usually of several seconds or several negotiations of additional delay. That's another limit sometime met, but likely that's NOT the one your are meeting.