On Sunday 19 March 2006 15:39, Chaskiel Grundman wrote: > > First, I should mention that with your patch, now the 0x65 control > > request happens before the T=1 negotiation. The original ifd-eutron.c > > and safesign both do it afterwards. My device doesn't seem to mind > > though. > > > > However, the 0x65 0x98 causes the device to fail. I must change it to > > 0x65 0x01. All other control codes seem to not make a difference, so > > I've left them alone. I've also noticed that I can just take out the > > 0x65 request and it still works. The problem is, I don't know if > > changing it or taking it out will break other cards. > > Was this true before, or only now that PTS is being done after the 0x65?
Doing 0x65 0x98 causes everything to fail, doesn't matter if it is before or after PTS. > > The device also doesn't like your PTS request. It will accept it, but > > then the device doesn't really do much from that point on. > > > > send: ff 11 18 f6 > > recv: ff 11 18 f6 > > send: 00 00 07 00 a4 00 0c 02 3f 00 92 > > recv: f8 > > > > OpenSC times out. I guess it wanted more than an f8. > > I wonder if the 0x65 request is setting some sort of "reader" parameters > (since the 0x98 in the original 0x65 request matches the 0x98 in the > original hardcoded PTS). This would imply that the usb device consists of > seperate "reader" and "icc" components that speak a serial protocol > (perhaps real ISO7816-[23]) to each other, and they each need > baud/frequency configuration. I noticed that too. I tried sending 0x65 pts[2] (which happens to be 0x18), but all that did was put opensc into some weird loop: send: ff 11 18 f6 recv: ff 11 18 f6 ctrl: 65 18 send: 00 00 07 00 a4 00 0c 02 3f 00 92 recv: 00 82 00 82 send: 00 c0 00 c0 recv: 00 82 00 82 send: 00 c0 00 c0 recv: 00 e0 00 e0 send: 00 00 07 00 a4 00 0c 02 3f 00 92 recv: 00 82 00 82 send: 00 c0 00 c0 recv: 00 82 00 82 send: 00 c0 00 c0 recv: 00 e0 00 e0 (repeat infinitely) I get similar issues if I try to pass 0x14 as the second byte, which is the SafeSign PTS value. It seems 0x01 is the only option. I've tried 0x98, 0x18, and 0x14 before and after PTS, all with failure. I can do 0x01 before and after PTS with no trouble. I can also not do the 0x65 request at all. A word about that last part: if I use these other values, then the serial stuff gets messed up. At that point, leaving out the 0x65 request no longer works. I must issue a 0x65 0x01 to make everything okay again (and takes about 3 or 4 runs of opensc-tool --atr to get back on track). -Justin _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
