[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