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. However, I modified ifd_protocol_select to force T=1 mode, and now I seem to get a little farther. # opensc-tool --atr 3b:b7:18:00:c0:3e:31:fe:65:53:50:4b:32:34:90:00:25 # opensc-tool --serial 04 90 50 55 00 18 2B 1D ..PU..+. # opensc-tool --name STARCOS SPK 2.3 The name seems odd. How can I get "MyCryptoCombo", which is the name I set with SafeSign? Now for more bad: # opensc-tool -vvvvvvvv --list-files [snip] card.c:221:sc_transceive: Sending 8 bytes (resp. 258 bytes): 00 A4 00 00 02 3F 00 00 .....?.. card.c:274:sc_transmit_apdu: Received 0 bytes (SW1=62 SW2=84) card.c:254:sc_transmit_apdu: called card.c:221:sc_transceive: Sending 7 bytes (resp. 258 bytes): 00 A4 00 0C 02 3F 00 .....?. card.c:274:sc_transmit_apdu: Received 0 bytes (SW1=90 SW2=00) card-starcos.c:356:starcos_select_fid: returning with: 0 card.c:770:sc_select_file: returning with: 0 3f00 type: DF, size: 0 select[N/A] lock[N/A] delete[N/A] create[N/A] rehab[N/A] inval[N/A] list[N/A] card.c:571:sc_list_files: called card.c:573:sc_list_files: returning with: Not supported sc_list_files() failed: Not supported [snip] This happens with or without those extra 9 exchanges in the init. I also tried removing the ATR from card-starcos.c (I had added earlier) just to see if the default driver would work. No luck. > Since it doesn't seem to break this device, I would put back the other > card_reset code you pulled out, since it might be needed with other > hardware (and it might deal with the extraneous 0 in the ATR, which is also > visible in the usb snoop log) I noticed that OpenSC seems to be aware of this. When the extra 0 appears, OpenSC reports: sc.c:540:_sc_parse_atr: invalid sync byte in ATR: 0x00 Maybe it is a common problem. I've noticed it happens immediately after insert. Every operation after that is fine. If a leading 0 is never good, perhaps I can account for it in eutron_init (ignore the first byte if 0). I wonder how SafeSign deals with it.. -Justin _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
