Thanks for the detailed report. Does the green LED blink fast when it does not work?

Thanks for prompt answer!

Yes, the LED blinks fast for ~5,5s and scdaemon log shows during that time:

reading public key failed: Card reset required
ccid_transceive failed: (0x10009)
apdu_send_simple(0) failed: card inactive
ccid_transceive failed: (0x10009)
apdu_send_simple(0) failed: card inactive
...

Is it an alias of SPR532? Please show me the USB vendor ID and product ID.

In our code for PC/SC, we have some code of workaround by detecting "SPRx32".
For the internal CCID driver, we also have a bit of code, but it is based on USB product ID of SPR532 (E003).

In general, if the vendor has to offer its proprietary driver, using without the driver won't work well...

Bus 001 Device 123: ID 04e6:e003 SCM Microsystems, Inc. SPR532 PinPad SmartCard Reader

A new device is on its way to you.

Here is the output for an SCM SPR532

bcdUSB               2.00
bDeviceClass            0 
bDeviceSubClass         0 
bDeviceProtocol         0 
bMaxPacketSize0        16
idVendor           0x04e6 SCM Microsystems, Inc.
idProduct          0xe003 SPR532 PinPad SmartCard Reader
bcdDevice            5.10
iManufacturer           1 SCM Microsystems Inc.
iProduct                2 SPRx32 USB Smart Card Reader
iSerial                 5 21250809205470
bNumConfigurations      1

My device has the same info but with firmware version (bcdDevice) of 7.01 butshows Identive SPR332 V2 on its printed label.

Thanks for sending.

I confirmed that Identiv distributing proprietary driver (libscmccid.so.5.0.3).

Just wanted to add to my initial findings:

• I was not using proprietary drivers (libscmccid.so.5.0.35), because the installer script fails to install on default CentOS 8 pcsc-lite. So the distribution pcsc-lite also doesn't have this issue.
• Fastest way to test this condition is to just detach/attach the reader device.
• Proprietary drivers doesn't support secure pin entry!

@turkja Thanks for your information.
May I ask you one thing?
Please show me the usb VID:PID of your card reader.
Is it 04e6:e003?
You can examine a line of the output by lsusb.

And please report the output of lsusb -d 04e6:e003 for the information of the card reader.

This is everything lsusb knows about the device:

Bus 002 Device 058: ID 04e6:e003 SCM Microsystems, Inc. SPR532 PinPad SmartCard Reader
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x04e6 SCM Microsystems, Inc.
  idProduct          0xe003 SPR532 PinPad SmartCard Reader
  bcdDevice            7.01
  iManufacturer           1 SCM Microsystems Inc.
  iProduct                2 SPRx32 USB Smart Card Reader
  iSerial                 5 51271834207869
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x005d
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          3 CCID Class
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower               90mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass        11 Chip/SmartCard
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              4 CCID Interface
      ChipCard Interface Descriptor:
        bLength                54
        bDescriptorType        33
        bcdCCID              1.10  (Warning: Only accurate for version 1.0)
        nMaxSlotIndex           0
        bVoltageSupport         7  5.0V 3.0V 1.8V 
        dwProtocols             3  T=0 T=1
        dwDefaultClock       4800
        dwMaxiumumClock     12000
        bNumClockSupported      0
        dwDataRate          12903 bps
        dwMaxDataRate      412903 bps
        bNumDataRatesSupp.      0
        dwMaxIFSD             254
        dwSyncProtocols  00000000 
        dwMechanical     00000000 
        dwFeatures       000104BA
          Auto configuration based on ATR
          Auto voltage selection
          Auto clock change
          Auto baud rate change
          Auto PPS made by CCID
          Auto IFSD exchange
          TPDU level exchange
        dwMaxCCIDMsgLen       271
        bClassGetResponse    echo
        bClassEnvelope       echo
        wlcdLayout           none
        bPINSupport             3  verification modification
        bMaxCCIDBusySlots       1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              16

Nice, thanks! If I want to try this fix, should I just compile the master tree?

Currently, yes. After some testing, I'll backport it to 2.2.

Ok. Tried to test this with master, but failed. I got it compiled and installed, and it actually detected the first removal after reboot/suspend/reader attach/whatever reason, but after that when I inserted the card back, it didn't function anymore. I suppose you also tried that? I mean that's the use case, I suppose: to be able to remove/insert the card reliably all day long.

I also had a lot of other troubles, like not getting pinentry to work at all, so I suspect my dev environment was not in good shape. Maybe the KVM/libvirt usb redirection was causing troubles as well, who knows. I'll just wait for official release and try again later, or try again with real physical usb bus.

I tested with physical usb, did multiple operations with external events (insert/remove/etc. for card). I haven't seen any problem (if so, I were doing more fixes), so far.

Let's see for a while, I'll keep testing.

Testing more, I managed to encounter failure with physical usb.
Once in this failure mode, I need to remove the card reader from USB and reinsert again.
I need to figure out a sequence to avoid this situation and to reset the card reader correctly.

It seems that, after re-insertion of card, there is some period for the card reader, which returns an error when accessed from host. When the card reader is accessed in this period, it seems it goes to unrecoverable state.

This is also what I found out with my tests with the libvirt usb: removing and redirecting back the device got it working again.

The patch rG684a52dffa8b: scd: Change handling of SPR532 card reader. makes me happier. It is more stable.

I observed that the card reader's going erroneous state when I removed a card during its communication.
In this state, it never reports the card removal by the interrupt transfer.
I applied rG920f258eb601: scd: Internal CCID driver: More fix for SPR532. for this problem.

I'm still having problems with 2.2.24. Now the card removal is detected correctly, but the initialization fails.

So if I try to do something requiring authentication, there seems to be a bit of a delay before pinentry hits, but it never asks for PIN, just fails.

Strange thing is that if I do "gpg --card-status" from terminal, it starts to work and asks PIN correctly, and authenticates.

Downgraded back to CentOS 8 default (2.2.9) and now I'm back in where it began: everything works but the first card removal.

Thanks again for your report.

I confirmed that the last change before the release breaks the use case in 2.2.
Fixed in rG84020385be19: scd:openpgp: Public keys should be available for check_keyidstr..

Stable now and works as expected. Thank you!