Re: MUSCLE Is 61xx handled in your driver?
The clean way to organise this is: (a) An application in the terminal issues APDUs (b) The software layer receiving the APDU knows whether the card is being operated with T=0 or T=1, and sends information down to the card driver as appropriate; if T=0 and a case 4 APDU, the APDU is split into a Case 3 TPDU (which sends data to the card) and a Case 2 GET RESPONSE (c) The card driver interfaces with a card reader driver (d) The card reader driver handles the interface out to the card reader Change the card - change only the card driver in the PC; change the card reader - change only the card reader driver in the PC Write the layer below the application strictly to 7816-4 rules, and cards that don't comply (e.g cards that require a GET RESPONSE as part of processing every APDU (if that really is true)) are not acceptable. Its sad that we cannot yet have a universal card driver, but its going to be true for some time to come. Regards, Peter T Bristol UK - Original Message - From: Laurent Boulard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 01, 2001 8:08 AM Subject: Re: MUSCLE Is 61xx handled in your driver? David Corcoran wrote: I think you should handle the Get Response if your APDU looks like the following: CLA INS p1 p2 p3 lentx xx xx xx xx xx lenrx Is this correct ? In the perfect world yes ! but, sadly, people sometimes doesn't follow correctly the ISO7816 or misunderstood it. I have cards (W4SC as an example) which send back a GET RESPONSE even for a APDU without data. This is really annoying as I have to modify my application to take care of this kind of cards. May be the highler level must be modify to hide this behaviour. But, from another point of view, it is interesting to know that you have a card with GET RESPONSE because sometimes those cards must run in terminals without management of the GET REPONSE apdus. -- Laurent Boulard Research Engineer Advanced Research SchlumbergerSema (Louveciennes) Tel: +33 (0)1 30 08 45 97 Fax: +33 (0)1 30 08 45 24 perl -e 'print(pack(h38,34f6e67627164757c6164796f6e63702b3d292))' *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** 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 ***
Re: MUSCLE Is 61xx handled in your driver?
CLA INS P1 P2 Lc data Le in 7816-4 speak (section 5.3.1 Fig 3) Peter T Bristol UK - Original Message - From: David Corcoran [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 31, 2001 9:26 PM Subject: Re: MUSCLE Is 61xx handled in your driver? I think you should handle the Get Response if your APDU looks like the following: CLA INS p1 p2 p3 lentx xx xx xx xx xx lenrx Is this correct ? Dave *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** 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 ***
Re: MUSCLE Is 61xx handled in your driver?
David Corcoran wrote: I think you should handle the Get Response if your APDU looks like the following: CLA INS p1 p2 p3 lentx xx xx xx xx xx lenrx Is this correct ? In the perfect world yes ! but, sadly, people sometimes doesn't follow correctly the ISO7816 or misunderstood it. I have cards (W4SC as an example) which send back a GET RESPONSE even for a APDU without data. This is really annoying as I have to modify my application to take care of this kind of cards. May be the highler level must be modify to hide this behaviour. But, from another point of view, it is interesting to know that you have a card with GET RESPONSE because sometimes those cards must run in terminals without management of the GET REPONSE apdus. -- Laurent Boulard Research Engineer Advanced Research SchlumbergerSema (Louveciennes) Tel: +33 (0)1 30 08 45 97 Fax: +33 (0)1 30 08 45 24 perl -e 'print(pack(h38,34f6e67627164757c6164796f6e63702b3d292))' *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
RE: MUSCLE Is 61xx handled in your driver?
Most readers wont handle this response code. Some POS terminals will. You should send the get response/data command to retrieve the data. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Naomaru Itoi Sent: Monday, July 30, 2001 6:43 PM To: [EMAIL PROTECTED] Subject:MUSCLE Is 61xx handled in your driver? When a card returns 61.xx, it means that the card has xx byte to return to host. Does a smartcard reader driver handle this, usually? Does it automatically send get_response APDU and get the return data, or does it pass the status code 61.xx to the application? I am not trying to find out which the right way is. I am trying to find out how the actual reader drivers do it. Thank you. -- Concentration .. Naomaru Itoi, coding @ home *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Is 61xx handled in your driver?
Hello, Most of the drivers pass the 61 XX back to the application to handle. I think it is bad practice to handle this in the driver since it is a card specific ISO function. This should happen above the reader abstraction where the card abstraction layer occurs. BTW - has anyone done an OSI like modeling for how a smartcard infrastructure should occur ? Regards, Dave On Mon, 30 Jul 2001, Naomaru Itoi wrote: When a card returns 61.xx, it means that the card has xx byte to return to host. Does a smartcard reader driver handle this, usually? Does it automatically send get_response APDU and get the return data, or does it pass the status code 61.xx to the application? I am not trying to find out which the right way is. I am trying to find out how the actual reader drivers do it. Thank you. -- Concentration .. Naomaru Itoi, coding @ home *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Is 61xx handled in your driver?
When a card returns 61.xx, it means that the card has xx byte to return to host. Does a smartcard reader driver handle this, usually? My Todos driver does. It seemed useful at the time. I would like to know whether this is correct or not. Most other reader drivers I have looked at do not. *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Is 61xx handled in your driver?
Hi, I completly agree with Andreas. Get Response is dependant on T=0 transport protocol and must not be handled at application level. This is at least what ISO 7816 says. Towitoko driver 2.0.X handles authomatically the Get Response when the command is Case 3 or Case 4. Also the issues athomatically the Envelope command and cares of extended commands (more that 255 bytes sent/received). --- Andreas Schwier [EMAIL PROTECTED] wrote: Most of the drivers pass the 61 XX back to the application to handle. I think it is bad practice to handle this in the driver since it is a card specific ISO function. GET RESPONSE is a transport level command. It should therefore be invisible for the application. The problem arises if you write applications that work with cards that support either T=0 or T=1 transport via PPS. If the reader hardware is capable of doing either T=0 or T=1, then the application always would need to know what protocol is used. If it is T=0, then it would need to send GET RESPONSE, if it is T=1 then it would not send a GET RESPONSE. ISO7816-4 was specifically rewritten at some point in time to eliminate dependencies on T=0. ISO7816-4 now defines command and response APDU in the first part and defines the mapping of these APDUs onto T=0 or T=1 transport in the annex. Andreas *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Is 61xx handled in your driver?
I agree that the application should not have to deal with this. But I don't think the driver should either. Anything that every driver must do in the same way really belongs at a higher level, in pc/sc. *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Is 61xx handled in your driver?
I think you should handle the Get Response if your APDU looks like the following: CLA INS p1 p2 p3 lentx xx xx xx xx xx lenrx Is this correct ? Dave *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
