--On Thursday, March 16, 2006 16:02:31 -0800 Justin Karneges
<[EMAIL PROTECTED]> wrote:
Yes, ifd-eutron.c looks quite simple. Syslog reports "eutron: failed to
activate token", which is in eutron_card_reset(), so I should probably
first look for problems there.
I would first attempt to remove the
ifd_usb_control(dev, 0x41, 0xa3, 0, 0, NULL, 0, -1) != 0
|| ifd_usb_control(dev, 0x41, 0xa1, 0, 0, NULL, 0, -1) != 0
from eutron_card_reset. your usb log didn't include them.
Could you briefly explain what each phase of this function is? There
seems to be a lot of calls to ifd_usb_control() in chunks or in loops.
First, a bit about ifd_usb_control
The second paramater is labeled "request type" it describes the data flow
0x41 is USB_ENDPOINT_OUT + USB_TYPE_VENDOR + USB_RECIP_INTERFACE (a write
request)
0xc1 is USB_ENDPOINT_IN + USB_TYPE_VENDOR + USB_RECIP_INTERFACE ( a read
request)
The third parameter is the "request". It's like a function code
the 4'th and 5'th parameters are labeled 'value', and 'index', but I don't
know what they're for, since neither the egate nor ccid make use of them.
From what I've been able to puzzle out, the function codes for the eutron
are as follows.
0x1 (write) is "write a blob of data" (seems to always be a T=1 thing)
0x2 (read) is "read a blob of data" (depends on context. can be atr or T=1)
0x9 (write w/no data) is "read ATR" (the windows trace shows it being used
twice, so it is probably independent of the magic reset sequence)
0xa3, 0xa2, 0xa1, 0xa0 and 0x65 are some sort of control requests. It's
hard to tell what they do.
The first block does some sort of reset, and requests the atr.
the loop immediately after it reads the atr in using multiple 0x2 operations
the "cookie" sent in the next block looks like a PTS (protocol selection)
request. Presumably this is used to enable T=1 TPDU's.
next, the PTS response is read and ignored
lastly, more magic sequences are sent. The 0x65 request actually uses the
'value' field. I still don't know what it is actually for.
Differences between eutron_card_reset and what safesign did:
safesign skipped the 0xa3 and 0xa1 reset requests, and only did
0xa2/0xa0/0x09
safesign sent a different PTS sequence (I don't have time to decode it now.
sorry)
safesign sent a different value with the 0x65 request (0x01 vs 0x98)
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
