[Pcsclite-muscle] Obtaining physical bus path of CCID devices via PC/SC?
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 :
> 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
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.
DWORD encoded as 0xDDDDCCCC, where DDDD = data channel type and CCCC =
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
Dr. Ludovic Rousseau
More information about the pcsclite-muscle