On Friday 17 March 2006 15:20, Justin Karneges wrote: > On Friday 17 March 2006 08:19, Chaskiel M Grundman wrote: > > it is openct's job to do the T=1 framing. The problem is that the > > device's ATR reports that it supports both T=0 and T=1. > > ifd_protocol_select picks T=0 (because it is reported earlier in the ATR) > > and tries to use it. Unfortunately, eutron_card_reset already put the > > device in T=1 mode. > > > > You could try not sending the PTS cookie at all and see what happens > > then. > > I tried this, but with no success.
Alright, I've looked at the ISO7816-3 document you referenced and I've decoded some bits. Just so I'm clear on this, both ifd-eutron and SafeSign are requesting T=1 mode with some parameters (parameters are in PTS1), and the card confirms T=1 with default parameters. So the card is confirming T=1, but rejecting the parameters. This is different from rejecting T=1 completely (which, as I read, is done by simply not responding at all). Therefore, this PTS data exchange is necessary, because it activates T=1. However, the SafeSign PTS sequence doesn't gain us anything more than the ifd-eutron PTS sequence, because the card rejects the "parameters" in either case, so for compatibility purposes we should leave the ifd-eutron PTS alone. Correct? Now, what I don't understand is why not sending PTS, and assuming T=0 protocol, fails to work. The card doesn't seem to default to T=1 either (I've taken out the PTS and forced openct to T=1 with no success). So it seems the PTS request is necessary -Justin _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
