On 06/17/2016 05:19 AM, Petter Reinholdtsen wrote:
> I tried to add udev setup as you proposed, ran 'service udev reload' and
> tested by unplugging and plugging in the smart card reader, without any
> luck.
I think that there is some problem for udev. When udev works, we can
see followng (my device is 234b:0000).
=====================
$ lsusb # identify bus and device number
Bus 001 Device 008: ID 234b:0000
Bus 001 Device 004: ID 04fe:0006 PFU, Ltd
Bus 001 Device 003: ID 04fe:0008 PFU, Ltd
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ ls -l /dev/bus/usb/001/008 # will have +, which means ACL
crw-rw-r--+ 1 root root 189, 7 Jun 17 11:43 /dev/bus/usb/001/008
$ getfacl /dev/bus/usb/001/008 # let's see the ACL
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/001/008
# owner: root
# group: root
user::rw-
user:gniibe:rw-
group::rw-
mask::rw-
other::r--
=====================
> The content of /run/user/1000/scd.log then looked like this:
Thank you. It seems that USB works well, but there is some problem in
the communication. If possible, it's good to compare the log between
RPi and another machine.
Let me explain the communication.
> 2016-06-16 22:17:00 scdaemon[9888] listening on socket
> `/tmp/gpg-8oZ6cr/S.scdaemon'
> 2016-06-16 22:17:00 scdaemon[9888] handler for fd -1 started
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: using CCID reader 0
> (ID=08E6:3438:0F9E69C2:0)
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: idVendor: 08E6
> idProduct: 3438 bcdDevice: 0200
[...]
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: PC_to_RDR_IccPowerOn:
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: dwLength ..........: 0
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSlot .............: 0
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSeq ..............: 1
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bPowerSelect ......:
> 0x01 (5.0 V)
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: [0008] 00 00
PC sends "PowerOn" command to ask card reader enabling the card with 5.0V.
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: RDR_to_PC_DataBlock:
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: dwLength ..........: 21
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSlot .............: 0
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSeq ..............: 1
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bStatus ...........: 0
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: [0010] 3B DA 18 FF 81
> B1
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: [0016] FE 75 1F 03 00
> 31 C5 73 C0 01 40 00 90 00 0C
PowerOn works, and card replys ATR data. It's OpenPGPcard V2, and
these bytes are parameters of the card (IFSC=254, 5V and 3V is
supported, etc.). This means that the reader successfully
communicates to the card and get the parameters' bytes.
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: PC_to_RDR_XfrBlock:
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: dwLength ..........: 4
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSlot .............: 0
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSeq ..............: 2
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bBWI ..............:
> 0x00
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: wLevelParameter ...:
> 0x0000
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: [0010] FF 11 18 F6
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: RDR_to_PC_DataBlock:
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: dwLength ..........: 4
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSlot .............: 0
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSeq ..............: 2
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bStatus ...........: 0
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: [0010] FF 11 18 F6
PC asks the reader to send setup PPS (protocol parameter selection) to
the card directly, using the third byte (0x18) of ATR. It successes
(the card echos the request).
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: PC_to_RDR_SetParameters:
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: dwLength ..........: 7
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSlot .............: 0
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSeq ..............: 3
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bProtocolNum ......:
> 0x01
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: [0008] 00 00 18 10 FF
> 75 00 FE
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: [0016] 10
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: RDR_to_PC_Parameters:
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: dwLength ..........: 7
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSlot .............: 0
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSeq ..............: 3
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bStatus ...........: 0
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: protocol ..........:
> T=1
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bmFindexDindex ....: 18
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bmTCCKST1 .........: 10
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bGuardTimeT1 ......: FF
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bmWaitingIntegersT1: 75
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bClockStop ........: 00
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bIFSC .............:
> 254
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bNadValue .........: 16
PC asks the reader to setup parameters for the card. It successes by
reader's echoing same values. Note that it depends on the
implementation of the reader, if it issues some commands to the
card or not.
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: PC_to_RDR_XfrBlock:
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: dwLength ..........: 5
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSlot .............: 0
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSeq ..............: 4
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bBWI ..............:
> 0x00
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: wLevelParameter ...:
> 0x0000
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: [0010] 10 C1 01 FE 2E
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: RDR_to_PC_DataBlock:
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: dwLength ..........: 4
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSlot .............: 0
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bSeq ..............: 4
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: bStatus ...........: 0
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: [0010] 00 82 00 82
> 2016-06-16 22:17:00 scdaemon[9888] DBG: ccid-driver: invalid response for
> S-block (Change-IFSD)
Here, it gets failure. Through the reader, PC send a S-block to the
card, and it's asking the change of the information field size to 254
(0xFE) (because the default is 32, and ATR says 254 is supported).
But, the card returns R-block with "Other error" (0x82).
This is fatal error, nothing can go with an error at this point.
> Does this tell you anything useful?
Yes, now, I understand the symptom. It failed at the last stage of
the function ccid_get_atr in gnupg/scd/ccid-driver.c.
I don't know the reason why it fails. Our options are:
(1) Figure out how it goes on other machine.
(2) Install pcscd and libccid and try with them.
This means, use PC/SC instead of ccid-driver.
--
