OK, I located the issue for ccid-driver. It is fixed in our repository. master: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=971064f8b7ad676326b2a468f688037a303717df
2.0.x: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=c68d39f7114623075c0b407b05927b61b190a377 I don't know if this is all for the problem, but it will improve the situation. The problem is: > 2016-06-18 09:29:42 scdaemon[1131] DBG: ccid-driver: dwFeatures > 00010230 > 2016-06-18 09:29:42 scdaemon[1131] DBG: ccid-driver: Auto clock change > 2016-06-18 09:29:42 scdaemon[1131] DBG: ccid-driver: Auto baud rate change > 2016-06-18 09:29:42 scdaemon[1131] DBG: ccid-driver: NAD value other than > 0x00 accepted > 2016-06-18 09:29:42 scdaemon[1131] DBG: ccid-driver: TPDU level exchange Here, the reader says that it supports NAD (node address) !=0. In the internal CCID driver, if it finds this, it uses NAD != 0. We had an issue for same vendor's device and we had a line: if (handle->id_vendor == VENDOR_GEMPC && handle->id_product == GEMPC_CT30) I changed it to: if (handle->id_vendor == VENDOR_GEMPC) so that all devices from the vendor won't use NAD !=0. I have another reader from the vendor, and I believe that this change makes sense and little impact for other devices, as libccid implementation always use NAD=0. On 06/18/2016 04:31 PM, Petter Reinholdtsen wrote: > I tried after installing pcscd, and got an error here too after ensuring > I had access to the device and the pcscd service were running: [...] > 2016-06-18 09:29:42 scdaemon[1131] PC/SC OPEN failed: unpowered card > (0x80100067) Umm... IIUC, it is pcsc service which let "power on" the card. I don't know why it fails. Running pcscd foreground with debug option shows more information (I mean, pcscd --foreground --debug). Please see: http://ludovicrousseau.blogspot.jp/2011/07/pcscd-debug-output.html --
