On Sunday 19 March 2006 20:32, Chaskiel Grundman wrote: > > 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: > > > > 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 > > This is sane (but unfortunate) T=1 control stuff. The first is > T1_R_BLOCK | T1_OTHER_ERROR (an error other than a checksum mismatch). The > second is T1_S_BLOCK | T1_S_RESYNC (request to resync). The R-Block error > response is repeated, as is the resync request. This time it succeeds, as > the last block is T1_S_BLOCK | T1_S_RESPONSE | T1_S_RESYNC (resync > succeeded)
It sounds so positive when you say succeeded. :) Too bad it is still just a dead end for us. > > 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. > > Have you try sending a0 00 after 65 xx, the way the original > eutron_card_reset worked? Yes, that's what I tried first. Ever since we determined I should leave all the harmless items in the eutron driver untouched (which was near the start of our discussion), a0 and friends have been sent. However, in my latest fiddling around I did try without it too, for testing purposes, but it never had an effect. > It probably won't help, but I'm about out of things to try. Maybe it's time to simply "make the darn thing work" ? We already know what bytes to send, even if we can't make sense of them. The hold-up seems to be the desire to retain compatibility with the existing eutron driver (which was written against some other token that none of you guys have anymore), by understanding the specific serial protocol behaviors. The problem is that pretty much anything we do risks breakage. For example, your protocol selection code "should" work, yet it doesn't work on my model. Imagine if it had worked, would we have patched it into openct? Isn't it just as likely that even if it worked on my model, the other eutron model could still throw a fit? Is changing the 0x98 to an 0x01 any more risky than using your function? We could branch the code by ATR. My model may have the same usb id as the one developed against for openct, but I'm pretty sure mine has a different ATR (since I had to add the ATR into the opensc starcos table). Since the protocol for obtaining the ATR works for both models, this should be very safe. -Justin _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
