[Pcsclite-muscle] Obtaining physical bus path of CCID devices via PC/SC?

Ludovic Rousseau ludovic.rousseau at gmail.com
Mon Sep 24 02:40:12 PDT 2018


Le dim. 23 sept. 2018 à 21:43, Ludovic Rousseau
<ludovic.rousseau at gmail.com> a écrit :
>
> Le dim. 23 sept. 2018 à 16:20, Harald Welte <laforge at gnumonks.org> a écrit :

> > If not, would it be acceptable to submit patches to that regard?  What would
> > be the preferred method to expose that bus path?  I was thinking of something
> > like an attribute that could be queried via SCardGetAttrib()?
>
> Use of SCardGetAttrib() is a good idea.
>
> The MSDN documentation provides SCARD_ATTR_CHANNEL_ID that could be used.
> Documentation: https://docs.microsoft.com/en-us/windows/desktop/api/winscard/nf-winscard-scardgetattrib
> DWORD encoded as 0xDDDDCCCC, where DDDD = data channel type and CCCC =
> channel number:
> The following encodings are defined for DDDD:
> 0x20 USB; CCCC is device number.
>
> But that may not be flexible enough for what you want.
>
> Another option is SCARD_ATTR_DEVICE_SYSTEM_NAME.
> The documentation is short: " Reader's system name. "
> I have no idea what values are returned on a Windows system.
> Maybe it is a free-format string and you could use it to encode the
> USB bus and port in an extensible scheme. Maybe something like
> "usb:port:number"

I used the attached Python script on Windows. This script uses
PySCard. You can find Windows installers of PySCard from
https://ci.appveyor.com/project/LudovicRousseau/pyscard so you don't
have to build anything.
It is easier for me to write a Python script than to create a C-code
project on Windows :-)
The Python script is a minor modification of this one
https://salsa.debian.org/rousseau/PCSC/blob/master/UnitaryTests/SCardGetAttrib.py

The result is:
Z:\>SCardGetAttrib.py
PC/SC Readers: ['Gemplus USB Smart Card Reader 0']
reader: Gemplus USB Smart Card Reader 0
0x20110 [5, 2, 32, 0] 05 02 20 00 ??
0x7fff0003 [71, 101, 109, 112, 108, 117, 115, 32, 85, 83, 66, 32, 83, 109, 97, 1
14, 116, 32, 67, 97, 114, 100, 32, 82, 101, 97, 100, 101, 114, 32, 48, 0, 0] 47
65 6D 70 6C 75 73 20 55 53 42 20 53 6D 61 72 74 20 43 61 72 64 20 52 65 61 64 65
 72 20 30 00 00 Gemplus USB Smart Card Reader 0
0x7fff0004 [71, 101, 109, 112, 108, 117, 115, 32, 85, 83, 66, 32, 83, 109, 97, 1
14, 116, 32, 67, 97, 114, 100, 32, 82, 101, 97, 100, 101, 114, 32, 48, 0] 47 65
6D 70 6C 75 73 20 55 53 42 20 53 6D 61 72 74 20 43 61 72 64 20 52 65 61 64 65 72
 20 30 00 Gemplus USB Smart Card Reader 0

SCARD_ATTR_CHANNEL_ID (0x20110) returns 05 02 20 00. 0x0020 for USB
and 0x0205 for the device number.
SCARD_ATTR_DEVICE_FRIENDLY_NAME_A (0x7fff0003) returns the same name
as reported by SCardListReaders(). This is the expected behaviour.
SCARD_ATTR_DEVICE_SYSTEM_NAME_A (0x7fff0004) also returns the same name.

For SCARD_ATTR_CHANNEL_ID I get different results if I connect the
reader on different USB ports. My guess is that the first byte (0x05)
is the bus number and the second byte (0x02) is the port number on the
bus.
If you do not have more than 256 USB buses or more than 256 port on
each bus then adding support of SCARD_ATTR_CHANNEL_ID (in the CCID
driver) may be the correct answer for your need.

Bye

--
 Dr. Ludovic Rousseau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SCardGetAttrib.py
Type: text/x-python-script
Size: 2305 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/pcsclite-muscle/attachments/20180924/5e757eb3/attachment.bin>


More information about the pcsclite-muscle mailing list