Hi, Then you may have a design problem in your driver. I know, T=0 is frustrating and does not follow a layered scheme.
You cannot tell your driver to receive Le bytes, because only the card knows how much it has to send. If you ask a different number, the card will say "I cannot answer because you don't ask me the right question, and I have no other way to tell it. Here is the correct length you have to ask me." So it sends 61 or 6C. If you get that, you have to be happy with that and return these bytes to the user even if he asked for more. See how it's done at http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/2b1a7d4b9ac6/src/share/classes/sun/security/smartcardio/ChannelImpl.java check doTransmit() at line 155. Note that the ScardTransmit method is called more than once, in a loop. pcsclite and winscard do not manage the get response command. so do the card drivers. A timeout is not acceptable because it would be too long and would not solve your problem. FYI, I don't know any reader that have to rely on timeouts. If I understand correctly, in the case the card does not give you Le bytes, you want to send the get response in the driver, just after the actual command? And what if the card DOES NOT have Le bytes at all? will you wait? it will never come :-) I would not do that. If the first byte you get is 61 or 6C, just get SW2 and return. The application will take care of the get response and send the proper command. Regards Sebastien On Wed, Jul 7, 2010 at 12:53 PM, Drasko DRASKOVIC < [email protected]> wrote: > On Wed, Jul 7, 2010 at 12:09 PM, Sébastien Lorquet <[email protected]> > wrote: > > Hi, > > > > APDU cases are deeply linked to T=0. In T=1, you don't need anything like > > this, because the block length is sent in the block header, before the > block > > data, so the peers know the data length. > > > > So I think the exchange transparency should be done at a higher level. > > > > In case 2, just send the 5-bytes apdu you get, do not change Le (P3) > > In this case, P3=Le=00 accounts for 256 bytes to be responded. > > > > Then, switch to receive mode. > > > > If the length is correct and accepted by the card, the card will answer > INS > > then the proper number of data bytes and SW. you do not need a timeout. > if > > the procedure byte is INS, the length you requested is valid and you will > > get that many bytes - plus final SW. > > > > If the length is not correct, the card will ALWAYS reply an error or > > warning, be it 61XX, 6CXX, or anything else. you also know that you just > > have 2 bytes to read, and the correct length. just go ahead with get > > response or command re-emission, now you know the correct length that > will > > be accepted by the card. > > Well this is exactly where the trouble comes : I told my driver to > receive Le bytes, > but card send him only 2. The driver keeps on waiting, because it does > know that these are errors/warnings. > > I can not go out of driver RX routine to process bytes, because I did > not know that it will receive only 2 bytes in the first place, > and going out after 2 bytes to my transport layer can result in RX > FIFO overflow (as driver is concerned he thinks that data is still > coming from the card). > > So - in this case how to know to stop drives RX after only two bytes ? > By looking at timeout (Work Waiting time exceeded) ? > > BR, > Drasko > > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.drizzle.com/mailman/listinfo/muscle >
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
