Is there a way , for me to see the TPDUs exchanged by the host and the reader, or at least to send the TPDUs myself, not to send the APDUs?
Thank you --- Peter Tomlinson <[EMAIL PROTECTED]> wrote: > In T=0 there is only one Get Response TPDU required > to be sent from the > reader for each case 4 APDU. > > 7816-4:1995 App A applies, and I'm only looking at > short commands and > responses (A.4): > > Case 4S.2 the card performed the command but does > not tell the reader how > long the response data is - card sends 90 00. The > reader may knows what > length to expect (issues a Get Response asking for > that length or any > greater length), or it may issue a Get Response with > Le = 00, and in both > situations the card sends all the data. > > Case 4S.3 the card performed the command and sends > 61 xx where xx is the > length of data available. The reader shall send a > Get Response asking for > the minimum of the length expected in the APDU or > the length from the > previous 61 xx response. So if the APDU said 'expect > 200 bytes' and the card > says 'I have 50 bytes', the Get Response sends 'send > 50 bytes'. But if the > APDU said 'expect 50 bytes' and the card says 'I > have 200 bytes to send', > the reader is supposed to send a Get Response asking > for only the 50 bytes. > > But 7816-4 is being rewritten, and we do not know > what changes have been > made (the authors refuse to produce a change list). > > Peter > ----- Original Message ----- > From: "Klauss Kirkegard" <[EMAIL PROTECTED]> > To: "Peter Tomlinson" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Tuesday, June 01, 2004 10:55 AM > Subject: Re: [OCF] TPDU/APDU > > > > > > In the ISO 7816-4 documentation in the Annex A > a > > 4-th case APDU is split in two TPDU. In the first > TPDU > > are snet the incoming data, and no expected length > of > > the answer. > > > > For this first APDU, there are two possible > answers > > from the card, one is the SW 90 00 , and the other > the > > SW 61 XX. > > > > As you say , the 90 00 is for agreeing with the > > reader the length of the response. But in the > first > > TPDU, the expexcted length is not known(after the > > first Get Reponse the expected length is known, > and > > after the second Get Response the card may agree > on > > the expected length). And I'm sure that the card > can > > return a status word of 61 XX for the first > incoming > > command TPDU. > > > > > > --- Peter Tomlinson <[EMAIL PROTECTED]> wrote: > > > An associate tells me that you never need to > send 2 > > > Get Response APDUs. He > > > says you get 90 00 if you asked for a specific > > > length of response and the > > > card agrees with you. 61 xx is the card telling > you > > > what it wants to send. > > > > > > But there is definitely the problem that some > card > > > readers handle the full > > > Case 4 processing, and some let the PC send the > Get > > > Response. Yet another > > > problem with interoperability and > interchangeability > > > of components in this > > > smart card area. > > > > > > Peter > > > > > > Peter Tomlinson > > > Bristol, UK > > > ----- Original Message ----- > > > From: "Klauss Kirkegard" > <[EMAIL PROTECTED]> > > > To: "Amitabh Pastore" > <[EMAIL PROTECTED]> > > > Cc: <[EMAIL PROTECTED]> > > > Sent: Monday, May 31, 2004 1:49 PM > > > Subject: Re: [OCF] TPDU/APDU > > > > > > > > > > > > > > Thank you Amitabh > > > > > > > > In the ISO7816-4 the 4-th case is split in > two > > > parts > > > > as you said. The first part the command APDU , > and > > > > after this a GETRESPONSE. The first command > APDU > > > is > > > > followed by an answer from the card, the > answer > > > can be > > > > SW=90 00 or SW=61 XX. > > > > > > > > I don't really understand, based on which > > > factors > > > > the JCRE responds to the host side with one > status > > > > word or the other. > > > > > > > > I'm thinking about the Javacard APIs, for > > > example > > > > the suite: SetOutgoing (returns the number of > > > bytes > > > > that the host side expects from the card), > > > > SetOutgoingLength(sets the length that the > card > > > wants > > > > to send to the reader), and SendBytes. > > > > > > > > So basically , and please correct me if I'm > > > wrong, > > > > in the 4-th case. > > > > First the incoming data are all read. The > card, > > > only > > > > when the applet developer calls the > SetOutgoing > > > > function, or when the process method > terminates > > > > without any call to a Outgoing function, at > this > > > > moment the card sends back the SW 90 00. > > > > After this, the host side, or the reader > sends > > > an > > > > apropiate GET RESPONSE command, and when the > > > applet > > > > developer calls the SetOutgoingLength, then > the > > > card > > > > responds with a TPDU containing a SW 61 XX. > After > > > this > > > > the host side again sends an TPDU with another > GET > > > > RESPONSE and in the 5-th byte of this GET > RESPONSE > > > the > > > > host side sets the XX received in the second > > > status > > > > byte from the card. > > > > > > > > After this second GET RESPONSE, the card > > > starts > > > > sending out the real bytes. > > > > > > > > Again in the 4-th case, if the card calls > > > first > > > > the SetOutgoingandSend method, with no call to > the > > > > SetOutgoing, SetOutgoingLength, SendBytes, > then > > > the > > > > card answers ( this is the first answer from > the > > > card > > > > after it has received all the incoming bytes) > with > > > a > > > > status word like SW 61 XX, and the host side > > > replyes > > > > with a GET RESPONSE with the 5-th bute set to > XX, > > > and > > > > after this the card starts sending out the > data. > > > > > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- > Visit the OpenCard web site at http://www.opencard.org/ for more > information on OpenCard---binaries, source code, documents. > This list is being archived at http://www.opencard.org/archive/opencard/ ! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email ! to ! [EMAIL PROTECTED] ! containing the word ! unsubscribe ! in the body.
