[Pcsclite-muscle] ScardControl under Linux?

[Francois Grieu]

I am trying to issue a ScardControl to a Smart Card reader. The code works under 
Windows (Identiv driver 4.65), but fails with 0x80100016 
(SCARD_E_NOT_TRANSACTED) under Linux Centos 6, pcscd 1.5.2

Am I missing something obvious?

If that matters: the reader is a Teo by Xiring/Ingenico SCR35xx 
(USB\VID_04E6&PID_5410) recognizable by having a green-only led, when the 
Omnikey variant (USB\VID_076B&PID_A022) has a led that briefly goes from green 
to red on card insertion. The ScardControl is intended to adjust the clock 
frequency to 8 MHz (after ATR and PPS negociation). It fails, and CLK remains as 
the default (I guess 4.8 MHz).

The code goes:

// SCM Microsystems Inc. SCR35xx (USB\VID_04E6&PID_5410) control code to change Clk
//
// To be issued only on this reader, after ATR and PPS negotiation, and after
// deep considerations on the risks.
//
// Second parameter controls the clock frequency, according to  f = 48/(48-n) MHz
//   n : 36   37       38     39       4   41       42   43    44
//   f :  4    4.364    4.8    5.333   6    6.857    8    9.6  12 MHz
//
// Many causes conspire to make use of this call risky:
//
// * For n>36 and absent a declaration in the ATR, f is larger than the minimum
//   for cards (5 MHz during ATR, 4 MHz after) specified by ISO/IEC 7816-3).
//   However:
//   - In my practice, the hardware of integrated circuits used for Smart Cards
//     manufactured after 2005 (resp. 1995) is explicitly specified to at least
//     8 MHz (resp. 5 MHz), and commonly 10 MHz.
//   - Usually, their software also works to that frequency;
//   - Commonly, it implements the turnaround delay specified by EMV when the
//     direction of communication on I/O changes;
//   - When that later condition applies at least, n = 42 works reliably,
//     and I have yet to see n = 43 fail.
//   - A card's TA1 (if present) states a value of  f  that the card promises
//     if usable; for example, TA1=B7h is a promises that the card accepts
//     f = 10 MHz. If it then accepts a PPS to
//   - a card can advertise
//
// * Propagation delays and capacitance conspire to deform clock.
//
// * For n odd and n>40 (perhaps n=39), the duty cycles is out of
//   ISO/IEC 7816-3 specs ( 40% to 60% ); however, in practice, cards are
//   quite tolerant on that if neither the maximum frequency nor minimum low
//   and high time are violated.
//
// * There is no insurance that when the clock switches, there is no glitch
//   violating said minimums.
//
// * ISO/IEC 7816-3 specs is ambiguous about if a card with TA1=00h or no TA1
//   must accept Clk about 4 MHz beyond the ATR; however, it is safe to assume
//   that any card made after 1995 does.
//
// * The values to use for the SCR35xx are undocumented AFAIK; the control code
//   is documented for another SCM reader, search CCID_ESC_CLK_FREQUENCY, or
//   http://www.epsys.no/downloads/pdf/RM_MAXX_lite.pdf
//
     const uint8_t rControlCode[2] = { 0x1F, 42 }; // n = 42, f = 48/(48-n) = 8 MHz
     uint8_t vBuf[4];    // placeholder for possible result (ignored)
     vResult = SCardControl (
         gReaderTable[Nb].gCardHandle,
         SCARD_CTL_CODE( 0xDAC ),
         rControlCode,
         sizeof(rControlCode),
         vBuf,
         sizeof(vBuf),
         &dwState
         );

-- 
   Francois Grieu