[Pcsclite-muscle] What's responsible to filter out Le in Case 4 C-APDUs under T=0?
ludovic.rousseau at gmail.com
Tue Feb 8 08:59:05 PST 2022
Le mar. 8 févr. 2022 à 17:31, Francois Grieu <fgrieu at gmail.com> a écrit :
> In essence, the suggestion is to pass SCardTransmit a C-TPDU, rather than a
> C-APDU as I do. That's feasible, and fixes the problem I'm having with this
> particular driver. However:
Note that the IdBridge K30 reader works in TPDU-level exchange mode.
Search for "dwFeatures" in
You may have a different behaviour with a APDU-level exchange reader.
Also I note that on GNU/Linux you get:
tst at tst-vb:~$ scriptor
No reader given: using Gemalto USB Shell Token V2 (B0948688) 00 00
Using T=0 protocol
Reading commands from STDIN
> 00 xx xx xx 06 xx xx xx xx xx xx 08
< 61 08 : 0x08 bytes of response still available.
The Le value 08 in the command is ignored.
I guess you also get "61 08" if you just send "00 xx xx xx 06 xx xx xx
xx xx xx" (without the Le).
I checked the libccid driver source code and the data is sent to the
I guess you would see the complete APDU on the USB cable.
Can you generate a pcscd trace as documented at
https://ccid.apdu.fr/#support to check that?
> So: is there some authoritative source on if and when ScardTransmit requires Le
> in a C-APDU to be stripped from it's input by the caller ?
I do not know any authoritative source for that question.
And it may depend on the reader exchange level (TPDU or APDU).
To answer your initial question: report the problem to the Windows
GemCCID driver author i.e. Gemalto/Thales.
Dr. Ludovic Rousseau
More information about the pcsclite-muscle