Hi, The Towioko driver starting with version 2.0.5 has a compilation option to select to work at ISO APDU level or at ISO TPDU level. Previous versions allways worked at ISO APDU level. The compilation option is --enable-ISO-t0. It's disabled by default, so thats why the driver ignores by default the Le parameter (there are more differences). If you enable this option you might see a behaviour similar to that of the Gemplus drivers.
There is a bit of ambiguity about how the driver should work for T=0 cards. To be strictly ISO 7816 compliant the driver should accept APDU's: issue Get Response (and Envelope) automatically, etc. But to be compliant with PCSC (and with most applications, like Musclecard), the driver must better work with TPDU's. That's why my driver offers both possibilities. In general I aggree with Jean Luc that all the drivers should present an APDU level interface. But that would mean to change things in PCSC. musclecard, and other applications that assume that they work at TPDU level. Carlos. --- Jean-Luc Giraud <[EMAIL PROTECTED]> wrote: > > On Tuesday, April 30, 2002, at 04:32 pm, Arno Wilhelm wrote: > > > Hello, > > > > > >> I believe this card is 7816 compliant. You should try to send the > >> command without the 0x03 in the end. I think the Towitoko driver > >> expects > >> you to send a TPDU (i.e. transport level commands for T=0 and not > >> applicative level commands (APDU)). It therefore ignores the final > > >> 0x03. > > > > Does that mean that the TPDU ignores the Le field of any APDU? > > If by Le you mean the length of the expected response, the first TPDU > > (command) ignores it, but the Get Response can use it (or use the > length > in 61 xx). > > > But in this case the 0x03 at the end belongs to the cryptographic > > checksum and not to the Le field of the APDU, I think !? Maybe > that's > > the problem? > > Maybe the wording in the card documentation is ambiguous and the 0x03 > > should not be added? > > >> In fact, for a case 4 command (Data IN and OUT), the proper APDU > is > >> CLA, > >> INS, P1, P2, Lc, Data, Le. > >> The Get Response is a transport level command > >> used in the T=0 protocol (it does not exist in T=1) and the > application > >> should ideally not have to send it. > > > > Hmm, that means that the reader should issue a GetResponseCommand() > by > > itself when it get's a return value of 0x61xx? > > If you send a TPDU (which you should not ideally), the driver should > probably let you do the Get Response. If you send a proper APDU, the > driver should do it for you. > > If you send APDUs, your application will work on T=1 or T=0 cards > without modifications. > > > > >> At any rate a TPDU with Lc < to the length of the data is not 7816 > >> compliant. > >> The driver does not give the response in place of the card: it > just > >> sends the Get Response automatically, if the status byte is 0x61 > xx. > >> BTW, the driver is not trying to be helpful, it is just conforming > the > >> standard when it receives a complete APDU. > > > > But that would mean that the Towitoko driver and the description in > the > > GPK Reference Manual is not conforming to the standard? > > I don't know for the Towitoko driver (maybe it conforms to the PCSC > standard which might say that you should send TPDUs but then would > not > be really ISO). For the card, it probably is an error in the > documentation. > > > > >> For the Gemcore driver, my wild guess is that it allocates memory > >> according to the Lc byte and then complains because there is too > much > >> data for the size of the buffer. > > > > That sounds very sensible. Think I am going to test that out and > post > > the results on this mailinglist. ( That might last till the > beginning > > of next week, since I am out of the house for the rest of the week. > ) > > > I hope it works! > > Cheers, > JLuc. > > *************************************************************** > Unix Smart Card Developers - M.U.S.C.L.E. > (Movement for the Use of Smart Cards in a Linux Environment) > http://www.linuxnet.com/ > To unsubscribe send an email to [EMAIL PROTECTED] with > unsubscribe sclinux > *************************************************************** __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com *************************************************************** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux ***************************************************************
