Enhancement #68

[stephan57160]

This patch uses new constants in PCSC (when available).
These new constants allow an access to USB parameters:

• bus_number
• device_address
• device_port
• product_id
• vendor_id

[stephan57160]

Following a discussion, on PCSC, new implementation is pushed, just now.

This 2nd version implements missing SCARD_ATTR_CHANNEL_ID, for USB devices.

[LudovicRousseau]

The code should also compile with ./configure --enable-twinserial
I think a #if !defined(TWIN_SERIAL) is missing for this case.

[stephan57160]

Tried to compile with --enable-twinserial, with no particular problem.
libccidtwin.so is now generated (when it was not), but that's almost all I can check.

[LudovicRousseau]

Try: ldd -r src/.libs/libccidtwin.so

[stephan57160]

[rasp-053]$ ldd -r ./src/.libs/libccidtwin.so 
undefined symbol: get_ccid_usb_bus_number	(./src/.libs/libccidtwin.so)
undefined symbol: log_xxd	(./src/.libs/libccidtwin.so)
undefined symbol: log_msg	(./src/.libs/libccidtwin.so)
undefined symbol: get_ccid_usb_device_address	(./src/.libs/libccidtwin.so)
	linux-vdso.so.1 =>  (0xbef57000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xb6f3c000)
	libc.so.6 => /lib/libc.so.6 (0xb6de0000)
	/lib/ld-linux-armhf.so.3 (0xb6f8b000)
[rasp-053]$

With #ifdef, I won't have the undef on get_ccid_usb_xxx(), but I'll get the undef on log_yyy().
OK. Adding #ifdef, as requested.

[stephan57160]

With #if ! defined() :

[rasp-053]$ ldd -r ./src/.libs/libccidtwin.so 
undefined symbol: log_xxd	(rpmbuild/BUILD/ccid-1.4.31/src/.libs/libccidtwin.so)
undefined symbol: log_msg	(rpmbuild/BUILD/ccid-1.4.31/src/.libs/libccidtwin.so)
	linux-vdso.so.1 =>  (0xbeffd000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xb6ebd000)
	libc.so.6 => /lib/libc.so.6 (0xb6d61000)
	/lib/ld-linux-armhf.so.3 (0xb6f0c000)
[rasp-053]$ 

[stephan57160]

I can squash both commits, if you prefer.

[LudovicRousseau]

Fixed in 1b4c6ac and 4c8c809

I also added a test in PCSC UnitaryTests/SCardGetAttrib.py at LudovicRousseau/PCSC@e667a43

[stephan57160]

Thx for all.

[stephan57160]

To summarize the whole:

• USB idVendor and idProduct can be retreived via existing call to
  ScardControl(CM_IOCTL_GET_FEATURE_REQUEST)
• USB bus and address can be retreived via this freshly completed call
  SCardGetAttrib(SCARD_ATTR_CHANNEL_ID)

[LudovicRousseau]

I am not sure the patch does what you want.

The USB address is NOT stable. It is an incrementing number.
Example. I connect a USB reader. lsusb gives me:

Bus 001 Device 012: ID 08e6:3437 Gemalto (was Gemplus) GemPC Twin SmartCard Reader

And SCardGetAttrib.py gives me:

0x20110 [12, 1, 32, 0] 0C 01 20 00 .. .
 USB: bus: 1, addr: 12

Now I unplug and replug the reader and I get:

Bus 001 Device 013: ID 08e6:3437 Gemalto (was Gemplus) GemPC Twin SmartCard Reader

and

0x20110 [13, 1, 32, 0] 0D 01 20 00 .. .
 USB: bus: 1, addr: 13

The USB address is NOT related to a physical USB socket. If I connect to another USB port but on the same USB bus then the number will just increase as if I reconnect on the same USB socket.

Maybe what you want to use is libusb_get_port_number()

[LudovicRousseau]

Fixed in 810b550

[stephan57160]

The port was in my initial request, yes, as physical (when no HUB is used).
I observe the same than you, if I unplug/plug the reader.

Anyway, on my side, I get the bus/address & port with an existing connection to libusb.
With the new ATTR_CHANNEL_ID, I can identify the reader matching the same bus/address.
It's a bit tricky, but I should be able to manage.

From my point of view, would be great to have all USB info (vendor, product, serial, bus, address, port and maybe some others) with a single call to CCID, as my application considers the reader like a USB device, before a card reader. This is possibly the same for some others implementations.

A kind of ListReadersInfo(), returning the DEVICE_NAME and the CHANNEL_ID (possibly some other things) of all the readers, in one shot, would be of a great help. Then, it becomes easier, for me (for us) to implement a kind of OpenDeviceByChannel(), for instance.

[LudovicRousseau]

I fully understand your request.
But the WinSCard API is supposed to be portable across Linux, macOS and Windows (and others). So it is not a good idea to implement "proprietary" extension.

Do you prefer to get the address or the port with SCARD_ATTR_CHANNEL_ID?

[stephan57160]

Address is better.
Then, it will match what we have with (at least on Linux) some system tools (lsusb, ...)

Rasp-040> lsusb -s 1:4
Bus 001 Device 004: ID 076b:5022 OmniKey AG 
Rasp-040> 

Note that the "device" is actually the USB Device Address, above...

I don't know why, but "port" is rather difficult to find, with those tools ;-)

[stephan57160]

I agree with your point, about the "proprietary extensions".
My goal was not to request something, specific to my application. It was more to provide an access to something more "system", that more people could use.
This is also why I suggested "system specific" options, with GetAttr().

[LudovicRousseau]

I also agree to use address instead of port.

For port we would need the full USB topology using libusb_get_port_numbers(). But that is not possible to send the result with just 1 byte.

[LudovicRousseau]

Documented at https://ludovicrousseau.blogspot.com/2020/04/scardattrchannelid-and-usb-devices.html