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)
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? It probably won't help, but I'm about out of
things to try.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
