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...)
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?
On 09/08/2011 11:08 AM, Sébastien Lorquet wrote:
Hi
I don't know the consequences but here are the facts:
T=1 can be seen as a state machine
When a command is sent an APDU in an I block, S(wtx) is a reply from
the card that requires more time to complete the command.
At startup, the card timeout is negotiated and if the card has not
completed the required computations within this timeout, it has to
reply this block.
the reader will reply with the same block, and the SWTX exchanges will
continue until the card has terminated the processing. When it's done,
the card will reply with the R-APDU in a final I-block.
Regards
Sebastien
Umberto Rustichelli aka Ubi <[email protected]> a écrit :
Dear all,
I'm not an expert of smart card readers nor of APDU commands but I'm
developing software that uses a mix of PKCS#11 modules since some time.
I gave a look to proto-t1.c but for sure you cannot guess the real
meaning of the error without sufficient background.
Using a new smart card reader, I'm experiencing some slowdown in
communication with the smart cards and I see this error in the logs:
proto-t1.c:479:t1_transceive() CT sent S-block with wtx=1
As the operations are completed anyway, so I guess this is rather a
sort of warning, but what does it mean (in human terms)?
Is there some issue in the communication and the driver must cope
with it by resending data (hence the slight slowdown)?
I'm currently forced to use old versions of the software involved
(see later), so the second question is: should I care about the
error? What could the consequenses be?
DETAILS:
system: Red Hat ES 5.4
SW versions: ccid 1.3.10, pcsc-lite-1.5.3
+ [opensc-0.11.8.tar.gz] + [pkcs11-helper-1.07.tar.bz2] + proprietary
PKCS#11 module libbit4ipki.so for InCard smart cards (version not
available)
The smart card readers:
Bus 001 Device 009: ID 072f:90cc Advanced Card Systems, Ltd ACR38
SmartCard Reader
Bus 001 Device 007: ID 072f:90cc Advanced Card Systems, Ltd ACR38
SmartCard Reader
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
