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

Ludovic Rousseau ludovic.rousseau at gmail.com
Sun Sep 23 12:43:39 PDT 2018

Le dim. 23 sept. 2018 à 16:20, Harald Welte <laforge at gnumonks.org> a écrit :
> Hi!

Hello Harald,

> I'm currently looking at building systems with a massive amount of chip
> card slots attached to one given (Linux) system.
> From the specification point of view, every USB-CCID device can have up to
> 256 slots (real-world devices up to 5 slots are available off-the-shelf),
> and pcsc-liste currently limits this by a preprocessor definition down to 16.
> Tou can have many of such devices attached to any number of USB buses of a system.

Patches for PCSC issue #4 and CCID issue #4 are also welcome: "use a
list instead of a fixed size array for 16 reader states"


> Even with more frequently found single-slot devices, as soon as you have multiple
> you will start to wonder how to access one specific of those devices from software.
> As soon as you have several readers attached, particularly if it's the same
> model/brand/firmware, the software is faced with the problem to disambiguate
> them.  If you want to access a given slot of a given reader, names like
>         "ACS ACR33 ICC Reader 01 04"
> as provided by pcsc-lite + libccid are not very useful, as the "01" (number of
> the ARC33 device in the system) depends on the order of USB enumeration.

If your readers have a (unique) serial number you can also use it to
differentiate them.
See "What is in a PC/SC reader name?"

See also SCARD_ATTR_VENDOR_IFD_SERIAL_NO that is already supported by
my CCID driver.

> In Linux systems, you can normally use the physical bus topology and hence
> the bus path to understand in which port of which hub a given device is plugged.
> This hierarchy is exposed in sysfs, and it is also exposed by libusb with
> libusb_get_port_path() / libusb_get_port_numbers().
> I was wondering if there is any method in pcsc-lite + libccid at this point
> to obtain the physical bus path of a given reader/slot?


> 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.

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

 Dr. Ludovic Rousseau

More information about the pcsclite-muscle mailing list