I am surprised. I have not changed the voltage selection code since a long time.

Can you generate a pcscd trace as described in https://pcsclite.alioth.debian.org/ccid.html#support for both the working RHEL and the non working Fedora?

Lodivic, this is not caused by any change in pcsc-lite-ccid. The reason why it works in RHEL is caused our patch applied there (and for some reason not upstream).

From the working log we can see that this card answers to 3V:

00000010 commands.c:244:CmdPowerOn Card absent or mute
00000003 commands.c:273:CmdPowerOn() Power up with 1.8V failed. Try with 3V.
[...]
00000018 eventhandler.c:403:EHStatusHandlerThread() powerState: POWER_STATE_POWERED

Similar log with the failed run without the above modification of the Info.plist:

00000014 commands.c:244:CmdPowerOn Card absent or mute
00000003 ifdhandler.c:1210:IFDHPowerICC() PowerUp failed

I don't have physical RHEL7 so I am not sure how the log looks in RHEL7. But the related patch was added as a result of the bug #1033788 and can be found (for example) in the CentOS 7 sources:
https://git.centos.org/blob/rpms!pcsc-lite-ccid/3dd85f55c8aacfa0704849e7b6cf46d4970b747b/SOURCES!ccid-1.4.10-voltage.patch

Not sure if this is upstream-wise or the voltage would be better changed in the XML. Bob will be able to refer more I guess.

If you need to patch the CCID driver you may just change a line in src/ifdhandler.c:

--- /var/folders/sg/t7kts8_n6j13n11r6_tgr36r0000gn/T//x9Zq69_ifdhandler.c   2016-09-30 14:25:39.000000000 +0200
+++ src/ifdhandler.c    2016-09-30 14:25:27.000000000 +0200
@@ -65,7 +65,7 @@ static pthread_mutex_t ifdh_context_mute
 
 int LogLevel = DEBUG_LEVEL_CRITICAL | DEBUG_LEVEL_INFO;
 int DriverOptions = 0;
-int PowerOnVoltage = VOLTAGE_5V;
+int PowerOnVoltage = VOLTAGE_1_8V;
 static int DebugInitialized = FALSE;
 
 /* local functions */

Note that the driver patch is NOT equivalent to changing the Info.plist file.
The order of the different voltages is not the same.


Jakub, can you post the ATR of the Coolkey card please? You can use pcsc_scan to get it.

Yes. The above was workaround as explicitly mentioned in the description of the bug.

The result of the scan looks like this (the card is not in your database):

Fri Sep 30 15:34:33 2016
Reader 0: OMNIKEY AG CardMan 3121 00 00
  Card state: Card inserted, 
  ATR: 3B FF 14 00 FF 81 31 FE 45 80 25 A0 00 00 00 56 57 53 43 36 35 30 03 03 38

ATR: 3B FF 14 00 FF 81 31 FE 45 80 25 A0 00 00 00 56 57 53 43 36 35 30 03 03 38
+ TS = 3B --> Direct Convention
+ T0 = FF, Y(1): 1111, K: 15 (historical bytes)
  TA(1) = 14 --> Fi=372, Di=8, 46.5 cycles/ETU
    86021 bits/s at 4 MHz, fMax for Fi = 5 MHz => 107526 bits/s
  TB(1) = 00 --> VPP is not electrically connected
  TC(1) = FF --> Extra guard time: 255 (special value)
  TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 
-----
  TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1 
-----
  TA(3) = FE --> IFSC: 254
  TB(3) = 45 --> Block Waiting Integer: 4 - Character Waiting Integer: 5
+ Historical bytes: 80 25 A0 00 00 00 56 57 53 43 36 35 30 03 03
  Category indicator byte: 80 (compact TLV data object)
    Tag: 2, len: 5 (issuer identification number, ISO 7812-1)
      Issuer identification number: A0 00 00 00 56
    Tag: 5, len: 7 (card issuer's data)
      Card issuer data: 53 43 36 35 30 03 03
+ TCK = 38 (correct checksum)

Thanks Jakub. I was expecting a Class indication (to indicate supported voltage) in TA(i) (i>2). But that is not the case :-(

You can submit your card using https://smartcard-atr.appspot.com/parse?ATR=3BFF1400FF8131FE458025A000000056575343363530030338

(In reply to Ludovic Rousseau from comment #5)
> If you need to patch the CCID driver you may just change a line in
> src/ifdhandler.c:
> 
> --- /var/folders/sg/t7kts8_n6j13n11r6_tgr36r0000gn/T//x9Zq69_ifdhandler.c  
> 2016-09-30 14:25:39.000000000 +0200
> +++ src/ifdhandler.c    2016-09-30 14:25:27.000000000 +0200
> @@ -65,7 +65,7 @@ static pthread_mutex_t ifdh_context_mute
>  
>  int LogLevel = DEBUG_LEVEL_CRITICAL | DEBUG_LEVEL_INFO;
>  int DriverOptions = 0;
> -int PowerOnVoltage = VOLTAGE_5V;
> +int PowerOnVoltage = VOLTAGE_1_8V;
>  static int DebugInitialized = FALSE;

Ludo was there a reason in not having it upstream?

(In reply to Nikos Mavrogiannopoulos from comment #8)
> Ludo was there a reason in not having it upstream?

AFAIK, it was the thing what Bob was trying to point out, that having it this way (or through the config) would slow down the card recognition for most of the cards (trying the lower voltages first, when most of our cards need 5V).

What was Bob trying to achieve was to try the 5V first and the lower later to remove the timeout penalty.

(In reply to Nikos Mavrogiannopoulos from comment #8)
> (In reply to Ludovic Rousseau from comment #5)
> > If you need to patch the CCID driver you may just change a line in
> > src/ifdhandler.c:
> > 
> > --- /var/folders/sg/t7kts8_n6j13n11r6_tgr36r0000gn/T//x9Zq69_ifdhandler.c  
> > 2016-09-30 14:25:39.000000000 +0200
> > +++ src/ifdhandler.c    2016-09-30 14:25:27.000000000 +0200
> > @@ -65,7 +65,7 @@ static pthread_mutex_t ifdh_context_mute
> >  
> >  int LogLevel = DEBUG_LEVEL_CRITICAL | DEBUG_LEVEL_INFO;
> >  int DriverOptions = 0;
> > -int PowerOnVoltage = VOLTAGE_5V;
> > +int PowerOnVoltage = VOLTAGE_1_8V;
> >  static int DebugInitialized = FALSE;
> 
> Ludo was there a reason in not having it upstream?

This bug report made me think again about the problem.
After some documentation reading (ISO 7816-3 and CCID) I pushed my proposed change upstream.
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pcsclite/CCID.git;a=commitdiff;h=ea7bedd2b3d30a884f43544c44f87ef779f011ef

The performance penalty is a good remark. I have not made time measurement. Jakub, do you have numbers so we can compare the 1.8V -> 3V -> 5V strategy that is now implemented upstream and the 5V -> 1.8V -> 3V implemented in the RedHat patch?

Thanks.
I don't have the numbers and I did not notice the speed difference on my laptop with PIV cards when I was changing the configuration in the Info.plist. But it might have been more significant years ago, when the patch was written (for RHEL6). Still, Bob can bring some more light into the case and made my assumptions more clear.

I made some tests. The speed difference may depend on the reader you use. In my case I get a x1.96 slowdown in the worst case (from 110 ms to 216 ms). An delay of 100 ms is not really noticeable at the human level. And that was the worst case with all the smart cards in my test.

My proposal to change src/ifdhandler.c is bogus and does not work.
I used the RedHat patch with some minor changes.

See https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pcsclite/CCID.git;a=commitdiff;h=df1173ee2f33ca0cf79090e4eb817b24a15c2d00

I implemented the Redhat patch because it was for RHEL and I didn't want to risk breaking customers of 5V cards. I think Ludovic's fix is probably the preferable fix. I expect low voltage cards to be come increasingly more common now that most readers and software support them.

In any case we should follow whatever Ludovic implements upstream in fedora.

The fix is now included in CCID 1.4.26
https://ludovicrousseau.blogspot.fr/2017/01/new-version-of-libccid-1426.html

pcsc-lite-ccid-1.4.26-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-bf5c27db38

pcsc-lite-ccid-1.4.26-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bf5c27db38

pcsc-lite-ccid-1.4.26-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.