2011/9/8 Umberto Rustichelli aka Ubi <[email protected]>: > Humm... the next question is required by my boss, and I'd like to know, > too... :) > > The scenario is this one: the smart cards in use belong to the same family > (InCard InCrypto v2) of others that we commonly use without this glitch, > just they are more recent. > The reader is totally different from the one we commonly use, that is > no issue: Omnykey 3121 + old InCrypto (serial 100...) > with issue: ACR38 + new InCrytpo (serial 700...)
The Omnykey 3121 [1] is an APDU reader and the T=1 protocol is implemented by the reader. The ACR38U [2] is a TPDU reader and the T=1 is implemeted by the driver (with the logs you see). > We're going to perform some tests, but regarding the negotiated time out, > which part is responsible for that? What does it depend on? > Reader? SW? Smart card? Is the smart card aware if the time required to > perform operations? > Can I change the timeout via some configuration file (our logs are filled up > of this message)? > As a rule of thumb, is it possible that the reader is responsible for the > slowdown, or is it never the culprit? I don't want to go into details. If you want more information you should read ISO 7816-3. Have you _measured_ a slowdown? What are the numbers? Note that readers are _not_ equivalent. Some readers are faster than others. Have a look at [3] with readers sorted by dwMaxDataRate. Bye [1] http://pcsclite.alioth.debian.org/ccid/readers/CardMan3121.txt [2] http://pcsclite.alioth.debian.org/ccid/readers/ACR38U-CCID.txt [3] http://pcsclite.alioth.debian.org/ccid/dwMaxDataRate.html -- Dr. Ludovic Rousseau _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
