However, eutron_send gets this:
00 a4 00 0c 02
This is not "t=1" format. Is opensc forgetting to frame the content
before
passing to openct?
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.
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)
Some responses to your earlier messages....
--On Thursday, March 16, 2006 18:25:16 -0800 Justin Karneges
<[EMAIL PROTECTED]> wrote:
The reset failure occurs later in the function. Specifically, it times
out in the second loop, because only 3 bytes come back instead of 4. I
changed the line "if (lr >= 4)" to read "if (lr >= 3)" as a hack, and
now the openct reset completes, but I don't know if this does any good.
Given how the card behaves, this was the right thing to do. I didn't think
it was legitimate for the pts reply to not be a copy of what the host sent,
but that's what's happening here. Actually, It seems that the card is
behaving properly (it is allowed to reject the PTS1 byte by not echoing
it), see section 3.4.b of
<http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-3.aspx>
> safesign sent a different PTS sequence
Is it: ff 11 14 fa ? I tried setting this as the new cookie data, but it
didn't have any apparent effect.
This is the safesign pts sequence, but the card rejected it (returning only
ff 01 fe) just like it rejected the sequence that ifd-eutron.c uses. You
should be able to revert this change
Another question: Does it matter that all the windows USB writes begin
with
42? In the openct driver, the init writes begin with 41, and the
"normal"
writes begin with 42. I tried changing the opensc driver to use 42 all
the
time, but again to no apparent effect.
Based on my understanding of usb, the "correct" values would seem to be
0xc0/0x40, as the requests are not being sent to an interface or endpoint
(the device _has_ no endpoints, so 0x42 is definitely "wrong"). It would
appear that the device ignores the recipient part of the requesttype, so it
doesn't really matter what it does.
I've extracted the exchanges from the snoop log here:
A T=1 TPDU (when lrc is used) looks like this:
NAD PCB LEN <APDU bytes> CK
NAD identifies the who the packet is being sent to (not interesting here,
since there's no separate "reader" to talk to)
PCB is the "procedure byte". there are a bunch of control bits. As this
serial channel is unlikely to ever have errors, we're only going to see
I-Blocks (information blocks; that is, blocks that transport data). The
0x40 byte of PCB is toggled after every exchange.
CK is an XOR checksum of all the previous bytes.
So:
00 00 05 00 70 00 00 01 74 (TPDU) => 00 70 00 00 01 (APDU)
etc.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
