Getting closer...
It seem like a step backwards to me though...
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?
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.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
