2011/2/27 Grant Olson <[email protected]>: > So I've dug into the ACR83 a little more trying to get it to work. > Haven't made much progress on the code, but I've made a lot of progress > on understanding what's actually going on. > > Once I setup an exception to get libccid to accept the device as a CCID > reader in spite of the bad class code, it generally seems to respond to > CCID commands in a basically correct way. I won't go as far as saying > that it's in any way compliant. > > A single command was locking up the device and causing libusb to stop > responding. > > The reader does not implement the feature CCID_CLASS_AUTO_IFSD. Because > of this, we try to run the function t1_negotiate_ifsd to set things up. > That sends the following exchange to the reader: > > 00000011 -> 000000 6F 05 00 00 00 00 0E 00 00 00 00 C1 01 F7 37 > 00007406 <- 000000 80 02 00 00 00 00 0E 00 00 00 6D 00 > > From what I'm seeing on the net, "6D 00" is a basic > error/not-implemented response code. In any case, from the verification > code in t1_negotiate_ifsd, it's clearly not the response that we're > expecting.
Are you still using the same card with ATR 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C? It looks like the reader is in APDU and not TPDU mode. Can you try with a T=0 card? > Is the IFSD negotiation command powering up the card when it works > correctly? No. PowerOn is done before. You get the ATR as the power on response. Good luck :-) -- Dr. Ludovic Rousseau _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
