This bug report is quite old and a lot of code has been improved. Thus please
re-open it if it persists with 2.1.3.

c3po: There is no need to sighup gpg-agent.
gpgconf --reload (or --kill) dirmngr is sufficent

Please see T1930. And if you have time, please
test it for PC/SC.
For GnuPG's internal CCID driver, you can use reader-port=1 for the case of a).
I don't know if partial match will be useful for internal CCID driver.

D291: 599_gpg2-scd-issue-1930-patch.diff

Thank you for your patch. I think that it is more useful.
Well, it will change the semantics of "reader-port" option slightly (exact match
to partial match).
In this case, isn't it more useful for users to allow default reader when no
match (my patch attached)?

Please let me know your name so that I can acknowledge your name as original
patch author.
Please test my patch.

Fix committed as 971d558e862db878a7310e06ed7116dbe36886ab.

Here's the lsusb output:

Bus 001 Device 002: ID 058f:9540 Alcor Micro Corp.
Device Descriptor:

bLength                18
bDescriptorType         1
bcdUSB               2.01
bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass         0 
bDeviceProtocol         0 
bMaxPacketSize0         8
idVendor           0x058f Alcor Micro Corp.
idProduct          0x9540 
bcdDevice            1.20
iManufacturer           1 Generic
iProduct                2 EMV Smartcard Reader
iSerial                 0 
bNumConfigurations      1
Configuration Descriptor:
  bLength                 9
  bDescriptorType         2
  wTotalLength           93
  bNumInterfaces          1
  bConfigurationValue     1
  iConfiguration          0 
  bmAttributes         0xa0
    (Bus Powered)
    Remote Wakeup
  MaxPower               50mA
  Interface Descriptor:
    bLength                 9
    bDescriptorType         4
    bInterfaceNumber        0
    bAlternateSetting       0
    bNumEndpoints           3
    bInterfaceClass        11 Chip/SmartCard
    bInterfaceSubClass      0 
    bInterfaceProtocol      0 
    iInterface              0 
    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       3700
      dwMaxiumumClock     12000
      bNumClockSupported      3
      dwDataRate           9946 bps
      dwMaxDataRate      688172 bps
      bNumDataRatesSupp.    138
      dwMaxIFSD             254
      dwSyncProtocols  00000007  2-wire 3-wire I2C
      dwMechanical     00000000 
      dwFeatures       000404BE
        Auto configuration based on ATR
        Auto activation on insert
        Auto voltage selection
        Auto clock change
        Auto baud rate change
        Auto PPS made by CCID
        Auto IFSD exchange
        Short and extended APDU level exchange
      dwMaxCCIDMsgLen       272
      bClassGetResponse    echo
      bClassEnvelope       echo
      wlcdLayout           none
      bPINSupport             0 
      bMaxCCIDBusySlots       1
    Endpoint Descriptor:
      bLength                 7
      bDescriptorType         5
      bEndpointAddress     0x81  EP 1 IN
      bmAttributes            3
        Transfer Type            Interrupt
        Synch Type               None
        Usage Type               Data
      wMaxPacketSize     0x0004  1x 4 bytes
      bInterval               1
    Endpoint Descriptor:
      bLength                 7
      bDescriptorType         5
      bEndpointAddress     0x02  EP 2 OUT
      bmAttributes            2
        Transfer Type            Bulk
        Synch Type               None
        Usage Type               Data
      wMaxPacketSize     0x0010  1x 16 bytes
      bInterval               0
    Endpoint Descriptor:
      bLength                 7
      bDescriptorType         5
      bEndpointAddress     0x83  EP 3 IN
      bmAttributes            2
        Transfer Type            Bulk
        Synch Type               None
        Usage Type               Data
      wMaxPacketSize     0x0010  1x 16 bytes
      bInterval               0

Binary Object Store Descriptor:

bLength                 5
bDescriptorType        15
wTotalLength           12
bNumDeviceCaps          1
USB 2.0 Extension Device Capability:
  bLength                 7
  bDescriptorType        16
  bDevCapabilityType      2
  bmAttributes   0x00000002
    Link Power Management (LPM) Supported

Device Status: 0x0000

  (Bus Powered)

For the scdaemon log, do you need it:

• with pcscd running or with GnuPG direct ccid implementation?
• in “working” condition (for example doing a gpg --card-status or gpg --sign)?
• during the “breakage” (doing a gpg --decrypt)
• in “broken” condition (after doing a gpg --decrypt).

Sorry if my report wasn't so clear. The broken behavior only appears:

• when using GnuPG ccid implementation (instead of pcscd);
• when doing a decrypt operation (maybe also an encrypt, I didn't check yet, but I'd be surprised since the smartcard hardly do any job here)

After trying a decrypt operation, the USB reader is in a non working condition, and I can only restore working condition by doing a reboot (I'v
tried to cut power to the USB bus but that doesn't seem enough).

Let me confirm. Does this bus still exist in recent version of gpg 1.4 and/or
2.0, 2.1?

I understand your case.

D292: 591_gnupg-2.0.27-pkcs11_reader_match.patch

Applied to master and 2.0.

I'll apply the patch. Thanks.

It seems that you missed the patch attached to the original submission, which
has all the required info: vendor ID is VENDOR_GEMPC (0x08e6), product ID is
0x3437, and the change to be applied indeed is in the internal CCID driver.

The reader is supported by PC/SC-lite, which never uses non-null NADs.

Could you please give more information, such as its USB vendor ID and product ID?
I assume that you are using GnuPG's internal CCID driver.
If you have a patch, please attach it here.
Is the reader supported by PC/SC-lite? If so, we could see how it is handled.

Right, it should work in 2.0.23.

@werner: I think, you mean 2.0.23

Should work in 2.0.13

On 2013-11-13 at 23:29 +0000, asdil12 via BTS wrote:

The fix for the login-data thing works fine.

The fix for the login-data thing works fine.

On 2013-11-12 at 21:29 +0000, asdil12 via BTS wrote:

asdil12 <dominik@heidler.eu> added the comment:

OK, I tested gnupg-2.0.22 with both patches applied, and it worked again.

I also noticed, that the pinpad won't be used - you would be asked via software

• (even if enable-pinpad-varlen was specified), if this

Login data .......: gpguser\n\x14P=6,8\n
thing was set on the card.

OK, I tested gnupg-2.0.22 with both patches applied, and it worked again.

I also noticed, that the pinpad won't be used - you would be asked via software

• (even if enable-pinpad-varlen was specified), if this

Login data .......: gpguser\n\x14P=6,8\n
thing was set on the card.

I tested on Archlinux (x86_64) applying my
patches on the current archlinux gnupg pkg.

On 2013-11-09 at 15:36 +0000, asdil12 via BTS wrote:

I just retried today using gnupg-2.0.22 with your patch, and it
failed again, if the enable-pinpad-varlen option was set:

the reiner reader also doesn't seem to work:

2013-11-09 17:00:48 scdaemon[7374] signatures created so far: 83
2013-11-09 17:00:48 scdaemon[7374] DBG: check_pcsc_pinpad: command=20, r=0
2013-11-09 17:00:48 scdaemon[7374] DBG: prompting for pinpad entry '||Please
enter the PIN%0A[sigs done: 83]'
2013-11-09 17:00:48 scdaemon[7374] DBG: send secure: c=00 i=20 p1=00 p2=81
len=24 pinmax=-1
2013-11-09 17:00:48 scdaemon[7374] DBG: response: sw=6B80 datalen=2
2013-11-09 17:00:48 scdaemon[7374] DBG: dismiss pinpad entry prompt
2013-11-09 17:00:48 scdaemon[7374] verify CHV1 failed: Card error
2013-11-09 17:00:48 scdaemon[7374] operation sign result: Card error
2013-11-09 17:00:48 scdaemon[7374] app_sign failed: Card error
2013-11-09 17:00:48 scdaemon[7374] updating slot 0 status: 0x0000->0x0007 (0->1)
2013-11-09 17:00:48 scdaemon[7374] sending signal 12 to client 4554

I just retried today using gnupg-2.0.22 with your patch, and it failed again, if
the enable-pinpad-varlen option was set:

one try:

2013-11-09 16:30:01 scdaemon[1536] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1
le=256 em=0
2013-11-09 16:30:01 scdaemon[1536] DBG: PCSC_data: 00 CA 00 C4 00
2013-11-09 16:30:01 scdaemon[1536] DBG: response: sw=9000 datalen=7
2013-11-09 16:30:01 scdaemon[1536] DBG: dump: 01 20 20 20 03 00 03
2013-11-09 16:30:01 scdaemon[1536] 3 Admin PIN attempts remaining before card is
permanently locked
2013-11-09 16:30:01 scdaemon[1536] DBG: check_pcsc_pinpad: command=20, r=0
2013-11-09 16:30:01 scdaemon[1536] DBG: prompting for pinpad entry '|A|Please
enter the Admin PIN'
2013-11-09 16:30:01 scdaemon[1536] DBG: send secure: c=00 i=20 p1=00 p2=83
len=24 pinmax=-1
2013-11-09 16:30:01 scdaemon[1536] pcsc_control failed: not transacted (0x80100016)
2013-11-09 16:30:01 scdaemon[1536] control_pcsc failed: 65547
2013-11-09 16:30:01 scdaemon[1536] DBG: dismiss pinpad entry prompt
2013-11-09 16:30:01 scdaemon[1536] verify CHV3 failed: General error

for the other try (with user pin), see attached log.

On 2013-10-16 at 06:16 +0000, asdil12 via BTS wrote:

You might use the known-
readers.txt from ccid
source, which lists usb-ids
and reader ames for
detection via pcscd. As
pcscd adds some text about
reader port to the string,
you can only match the
beginning of the string, but
that should do it.

You might use the known-
readers.txt from ccid
source, which lists usb-ids
and reader ames for
detection via pcscd. As
pcscd adds some text about
reader port to the string,
you can only match the
beginning of the string, but
that should do it.

On 2013-10-15 at 22:53 +0000, asdil12 via BTS wrote:

I applied your patch onto gnupg-2.0.22 source (I couldn't get the automake-foo
run through), and it worked again. (enable-pinpad-varlen set in config).
I used the cherry reader for testing.

I applied your patch onto gnupg-2.0.22 source (I couldn't get the automake-foo
run through), and it worked again. (enable-pinpad-varlen set in config).
I used the cherry reader for testing.

For auto detection of pinpad, it does the detection itself.

But the reader only works when we have some information on card [0] or
configuration of enable-pinpad-varlen.
That's because there is no good standard way to detect reader's capability
for variable length input.

Internal ccid driver has better support for variable length input detection
based on its USB ID.

It is currently, out of sync and it only works for SCM SPR 532.
I will add KAAN, FSIJ, REINER, VASCO, and CHERRY for PC/SC with USB ID, too.
I need users' help for PC/SC for detection with card reader name.

[0] http://wiki.gnupg.org/CardReader/GemaltoPC

Fixed in 2.0.x and master in git repository.
Please test it out.

BTW: shouldn't scd autodetect pinpad
support, or does this only work when using
internal ccid driver insted of pcsc?

Err... Sorry for your troubles. It's my fault.

my scdaemon.conf:
reader-port Cherry GmbH SmartTerminal ST-2xxx [Vendor Interface]
(21121310161160) 00 00
verbose
debug 2048
enable-pinpad-varlen
log-file /tmp/scd-pinpad.log

Can you please provide a debug log? Put the lines

verbose
debug 2048
log-file /foo/bar/scd.log

into ~/.gnupg/scdaemon.log - kill sdaemon and try again. Note that the PIN may
show up in the log.

Just tested with Cherry SMARTTERMINAL ST-2000U (via pcsc -> ccid).
Same issue with that reader, so not related to reiner-driver.

When I don't set the "enable-pinpad-varlen" option, pin-validation is done via
pc keyboard, if I do set the option, the complete action fails without asking
for the pin in any kind:

scdaemon[5137]: DBG: prompting for pinpad entry '||Please enter the PIN%0A[sigs
done: 46]'
scdaemon[5137]: DBG: dismiss pinpad entry prompt
scdaemon[5137]: verify CHV1 failed: Invalid value
scdaemon[5137]: app_sign failed: Invalid value
gpg: signing failed: Invalid value
gpg: signing failed: Invalid value

And pcscd must be restarted then, to get the setup working, again.

Meanwhile gniibe fixed a lot more bugs and also ported them back to 2.0. Thus I
close this bug.

No, I can't reproduce the problem. I just came to check the status of the bug.
Thanks for the info werner.

It was set to resolved in 2011 because I was not able to replicate it. Are you
now able to replicate the problem?

Hi!

Is this bug solved? And if yes, in what version is resolved?

I will stay prepared for any testing or debugging that might be requested by
anyone of you guys (but it might take a week, as the reader belongs to someone
else), such a warning could have saved lots of time for each one of us.

And, only for your files, I made a mistake in the first E-Mail I wrote Ludovic:
It's not a Cherry ST-1044U, but a Cherry XX44 smartcard reader (ST-1044U seems
to be the USB-Descriptor)

I just fixed a couple of card reader problems in GIT master. I assume that
theses fixes will also solve your problem.