On 08/05/2016 10:52 PM, Petter Reinholdtsen wrote:
> fbx@freedombox:~$ sudo chmod a+rw /dev/bus/usb/001/00*
> fbx@freedombox:~$ gpg2 --card-status
> Reader ...: 08E6:3438:C4CC14F3:0
> Application ID ...: D27600012401020100054202
> Version ..: 2.1
> Manufacturer .:
Thank you for the quick response. I still had the test box ready, which
made it easier to test some more. :)
[NIIBE Yutaka]
> In 2.1.14, libusb has been changed, so, the error message is
> different, but it also means access error. It's highly likely access
> permission problem.
Aha.
>
On 08/05/2016 09:01 PM, Petter Reinholdtsen wrote:
> I decided to test again using an FreedomBox image to reduce the
> difference since my initial testing. First I tested using version
> 2.1.11-7 in Debian testing, and then using version 2.1.14-1 in Debian
> experimental. Both fail. First the
[NIIBE Yutaka]
> I see the situation. I have no idea about the segmentation fault.
>
> I don't know if the difference of armel/armhf matters or not. My
> point was that in order to narrow down an issue (to be fixed), in
> general, it would be better not to change other factors.
>
> While I guess
On 08/03/2016 10:10 PM, Petter Reinholdtsen wrote:
> My original test was done using a Freedombox image, which was armel.
>
> Todays test was done using some random RPi and SD card I found on my
> desk and I did not notice it was using a different architecture. I can
> try again on armel, if you
[NIIBE Yutaka]
> arm-linux-gnueabihf ? Your original report says "armel" in the
> subject.
>
> According to https://wiki.debian.org/RaspberryPi, it seems armel.
My original test was done using a Freedombox image, which was armel.
Todays test was done using some random RPi and SD card I found on
On 08/03/2016 09:03 PM, Petter Reinholdtsen wrote:
> Thank you. I just tested on a Raspberry Pi using the gnupg2/scdaemon
> version 2.1.14-2 in Debian experimental, and this now segfaults when I
> try 'gpg2 --card-status'. But for some reason I can't get info from
> valgrind, so here is the
[NIIBE Yutaka]
> 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:
>
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
[NIIBE Yutaka]
> It worked well with PC/SC service. You can try to run PC/SC service
> on RPi, too.
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] listening on socket
On 06/17/2016 10:38 PM, Petter Reinholdtsen wrote:
> Here is the same output from 'gpg2 --card-status' on a amd64 machine:
Thanks a lot. OK, it works on amd64 machine with PC/SC service.
> 2016-06-17 15:34:07 scdaemon[8236] DBG: ccid-driver: using CCID reader 0
> (ID=08E6:3438:X:0)
>
[NIIBE Yutaka]
> 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.
Here is the same output from 'gpg2 --card-status' on a amd64 machine:
2016-06-17 15:34:06 scdaemon[8236]
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
[NIIBE Yutaka]
> It successfully got the information of the USB device. But, if fails
> at usb_claim_interface. After that, it tries to use PC/SC, and fails too
> (because there is no PC/SC service on your host).
>
> Most common cause of failures at usb_claim_interface is permission
> problem.
On 06/12/2016 04:51 AM, Petter Reinholdtsen wrote:
> Hi, and sorry it took so long before I had time to revisit this issue.
No problem.
>> (4) To debug scdaemon, please have the following configuration file.
>> Note that it may log your PIN information, so, don't send the log
>> when you
Hi, and sorry it took so long before I had time to revisit this issue.
[NIIBE Yutaka 2016-04-26]
> Here are some information and somethings to try.
>
> (1) Power consumption of smartcard readers/token is small. For
> example, it's just a few mA for Gnuk Token. So, I don't think
> power
On 03/31/2016 04:56 PM, Petter Reinholdtsen wrote:
[Petter Reinholdtsen]
My only ideas is something is wrong with the armel architecture
support of some of the packages involved, or the Raspberry Pi is
unable to provide enough power to the smart card reader and smart card
for the smart card to
On Thu 2016-03-31 03:56:35 -0400, Petter Reinholdtsen wrote:
> [Petter Reinholdtsen]
>> My only ideas is something is wrong with the armel architecture
>> support of some of the packages involved, or the Raspberry Pi is
>> unable to provide enough power to the smart card reader and smart card
>>
[Petter Reinholdtsen]
> My only ideas is something is wrong with the armel architecture
> support of some of the packages involved, or the Raspberry Pi is
> unable to provide enough power to the smart card reader and smart card
> for the smart card to work. Not quite sure how to figure out if
Package: gnupg2
Version: 2.1.11-5
Severity: important
Hi.
I'm trying to get a GnuPG smartcard working with gnupg/gnupg2 on a
Raspberry Pi running Freedombox (ie Debian armel). This do not work.
I'm not sure if the problem is in gnupg2 or some other package (like
pcscd, scdaemon or the kernel).
20 matches
Mail list logo
