On Saturday 18 March 2006 08:40, Chaskiel Grundman wrote: > On Fri, 17 Mar 2006, Justin Karneges wrote: > > send: 00 c1 01 fe 3e > > recv: 00 e1 01 fe 1e > > The 0x40 bit is set in here, but of course there are others too. I'd > > also like to find out what the meaning of the content is as well (0xfe), > > to determine whether or not this exchange belong in eutron_init. > > It appears that the bits are not actually independent. 0x40 is only the > sequence bit in I-Blocks, which do not have bit 0x80 set. > > this is a T1_S_BLOCK + T1_S_IFS request. safesign is negotiating a higher > T=1 block size with the device (and it succeeds). > eutron_init/eutron_card_reset should not do this, since openct's T=1 state > machine would not be prepared for it.
Alright, so we have to hope the card will work properly even without this upgrade mode? Why does openct not support it? > > 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 > > It is unlikely that the card actually implements real T=0 framing when in > T=0 mode. In T=0, you send the first 5 bytes of the APDU, and then read an > ack byte. depending on its value, you either send data, recieve data, or > recieve status words. When dealing with slow serial devices, this saved > time. with usb devices, it costs time, and so they don't do it. > > Try the attached patch. It introduces eutron_set_protocol. The only > functional change is that it tells T=0 that the device is "block > oriented", so it doesn't try to do it's own chunking. > > eutron_set_protocol could be enhanced further to perform the PTS exchange I tried the patch. openct calls eutron_set_protocol with t=0, as expected. And I removed the t=1 negotiation from eutron_card_reset. And according to my logs, all 7 bytes of the first opensc request are now sent instead of just the first 5. send: 00 a4 00 0c 02 3f 00 recv: a4 After 9 read attempts, the card replies with a single 0xa4. However, this doesn't seem to satisfy openct, and so there are another 200+ attempted reads until it gives up and returns an error. Was the card supposed to reply with more data? I guess t=1 is required? Maybe the card is lying about supporting t=0 or it is buggy. -Justin _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
