[Pcsclite-muscle] What's responsible to filter out Le in Case 4 C-APDUs under T=0?

[Ludovic Rousseau]

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
https://ccid.apdu.fr/ccid/readers/Gemalto_IDBridge_K30.txt

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
reader as-is.
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.

Bye

-- 
 Dr. Ludovic Rousseau