On 09/08/2014 10:02 AM, helpcrypto helpcrypto wrote:
On Mon, Sep 8, 2014 at 9:30 AM, Umberto Rustichelli <
[email protected]> wrote:
...a few millions consecutive signatures for each card (what you wouldn't
do to meet the absurd customers' demand!)...
omg
To make it short, does anybody know of any predictable limit that can
cause failures (after "many" signatures the *cards disconnect*, one by one)
among the following:
- cards cannot reliably work for more than N signatures
If it's a chip-writing limit issue, the card shouldnt be able to write
after reconnect. Have you tried that?
When the smart card fails, I physically disconnect it then restart the
procedure, then it works, but apparently every time we restart the cards
the time-to-failure gets shorter, that is why I am suggesting a wearing
issue, whether it is due to the smart cards flash/EEPROM, the readers
(really? I don't buy it) or anything else.
I'm sorry for not having much detail to provide but this is a production
system and every restart is a painful operation with
administrative/managerial consequences, debugging is almost impossible.
Thanks a lot
- some counters in the PCSC / CCID code
You can try stopping pcscd service and powering off devices each x-million
operations to discard this.
- any known issue with smart card drivers,
I dont know how you doing, but I suggest doing independent operations (ie:
use establishContext/releaseContext)
Whats the current operation limit?
Perhaps the amount of operations done is much more clarifying for us.
Consider, for example, PCSC dwCurrenStatus has a limit of bits to notify
card changes (including card resets).
Did anybody try such massive use of cards?
Not me.
Why on earth...?
_______________________________________________
Pcsclite-muscle mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
