Philip Jackson <philip.jack...@nordnet.fr> wrote:
> I created the scdaemon.conf file as you suggested and then ran a decrypt
> test :
Thank you.
> Perhaps there is something you can see which explains the problem ?
As far as I can see, it looks like no problem of scdaemon, but card
failure.
Here is the decrypt operation started:
> 2017-09-15 00:30:20 scdaemon[8306] DBG: send apdu: c=00 i=2A p1=80 p2=86
> lc=257 le=2048 em=1
Since it's long command, it is devided into two blocks, (1) and (2).
This is the first block (1):
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: PC_to_RDR_XfrBlock:
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: dwLength ..........:
> 258
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSlot .............: 0
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSeq ..............: 29
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bBWI ..............:
> 0x04
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: wLevelParameter ...:
> 0x0000
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: [0010] 00 20 FE 00 2A
> 80
^
The first block has "more"-bit --------------------------------------
Then, this is the reply asking next block:
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: RDR_to_PC_DataBlock:
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: dwLength ..........: 4
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSlot .............: 0
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSeq ..............: 29
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bStatus ...........: 0
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: [0010] 00 90 00 90
This is the next block (2):
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: PC_to_RDR_XfrBlock:
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: dwLength ..........: 16
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSlot .............: 0
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSeq ..............: 30
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bBWI ..............:
> 0x04
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: wLevelParameter ...:
> 0x0000
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: [0010] 00 40 0C FD E0
> 81
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: [0016] 35 DD 4C B4 CA
> 38 6E 08 00 54
This block is final with no "more" bit.
The expected behavior is the card reader returns text after decryption by card.
But, card reader returns only three bytes, where more than four bytes
are expected at least.
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: RDR_to_PC_DataBlock:
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: dwLength ..........: 3
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSlot .............: 0
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bSeq ..............: 30
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: bStatus ...........: 0
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: [0010] 00 00 00
So, it is interpreted as lower-level communication error.
> 2017-09-15 00:30:20 scdaemon[8306] ccid_transceive failed: (0x1000d)
> 2017-09-15 00:30:20 scdaemon[8306] apdu_send_simple(0) failed: aborted
Sending APDU, the command is somehow aborted.
> 2017-09-15 00:30:20 scdaemon[8306] operation decipher result: Operation
> cancelled
> 2017-09-15 00:30:20 scdaemon[8306] app_decipher failed: Operation cancelled
> 2017-09-15 00:30:20 scdaemon[8306] DBG: chan_5 -> ERR 100663395 Operation
> cancelled <SCD>
> 2017-09-15 00:30:20 scdaemon[8306] DBG: chan_5 <- CAN
> 2017-09-15 00:30:20 scdaemon[8306] DBG: chan_5 -> ERR 100663571 Unknown IPC
> command <SCD>
This part is a little buggy, though. The error code of GPG_ERR_CANCEL
is not that appropriate, I suppose. Because of erroneous
GPG_ERR_CANCEL, gpg-agent wrongly send "CAN" (cancel) command to
scdaemon, which is unknown by scdaemon in this stage. I'll fix this
part.
I don't know the reason why card error occurs.
--
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
