Re: gpg-agent has to be restarted after GnuPG SmartCard pulled from reader

[gnupg-users . dirk]

Hi all,

thank you Damien and Werner for your recent replies.
Even if the reader is performing o.k. now to my amassment.
When I used the feature to create the keys on the card I ran to some
strange and not reproducible problems.
I think this is what Werner refers to. Once I decided to create the keys
on my PC and uploaded them to the Card everything works fine.

For the time being I think the solution is to go for scd-event. This
obviously beats to tail the logs. I will try this as soon I will get to it.

However - for me it really looks like the scdaemon or gpg-agent are not
handling the existing events correctly. It might be worth looking into
it as well.
I will not rule out misconfiguration by ubuntu or myself.

Recent publications are giving up on PGP/GPG which is clearly wrong in
my humble opinion. The key questions is for all crypto -> how to
securely store your key.
Even if SmartCards and alike (Yubikey) are "old fashioned" and geek
technology I think for security they are irreplaceable.

Thanks and best regards

Dirk


On 06.01.2017 20:23, Werner Koch wrote:
> On Fri,  6 Jan 2017 14:52, dgouttegat...@incenp.org said:
>
>> For what is worth, I have two such readers, which are working
>> flawlessly with the ccid driver [1] and with 2048-bit keys. I have not
>> tried them with the internal driver.
> IIRC, I added some workarounds but eventually gave up due to too many
> problems.  Key generation always failed with Omnikey based readers and
> signature creation only works in some cases.  
>
> I have a whole bunch of those readers and they are all crap.  Well,
> except for the Cherry keyboard, it does work well in the server room
> (w/o card).
>
>> the file $GNUPGHOME/scd-event exists and is executable, it will be
>> called on every card reader status change.
> I was about to tell this, too ;-)
>
>
> Salam-Shalom,
>
>Werner
>
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-agent has to be restarted after GnuPG SmartCard pulled from reader

[Werner Koch]

On Fri,  6 Jan 2017 14:52, dgouttegat...@incenp.org said:

> For what is worth, I have two such readers, which are working
> flawlessly with the ccid driver [1] and with 2048-bit keys. I have not
> tried them with the internal driver.

IIRC, I added some workarounds but eventually gave up due to too many
problems.  Key generation always failed with Omnikey based readers and
signature creation only works in some cases.  

I have a whole bunch of those readers and they are all crap.  Well,
except for the Cherry keyboard, it does work well in the server room
(w/o card).

> the file $GNUPGHOME/scd-event exists and is executable, it will be
> called on every card reader status change.

I was about to tell this, too ;-)


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp6N3ShYkfPx.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-agent has to be restarted after GnuPG SmartCard pulled from reader

[Damien Goutte-Gattat]

On 01/06/2017 10:06 AM, gnupg-users.d...@o.banes.ch wrote:

I was under the impression the OmniKey 3121 is a real reader since it is
on the how to [1].


For what is worth, I have two such readers, which are working flawlessly 
with the ccid driver [1] and with 2048-bit keys. I have not tried them 
with the internal driver.




What would be a good alternative bevore I buy another bad one.


I also have a SCM 3500 reader from SCM Microsystems (now Identiv), again 
working flawlessly with the ccid driver.




p.s. in the meantime a made a script which tails the scdaemon.log and
waits for "Removal of a card:"
and then kills the gpg-agent. Not a proper solution - but working so far.


Instead of watching the log, you could use a feature of Scdaemon: if the 
file $GNUPGHOME/scd-event exists and is executable, it will be called on 
every card reader status change.


For example, to act upon card removal, you could have the following:

  #!/bin/sh

  case "$8" in
  NOCARD)
  # do something
  ;;
  esac

See doc/examples/scd-event in GnuPG's source for more details of what 
this script can do.



Damien


[1] http://pcsclite.alioth.debian.org/ccid.html



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-agent has to be restarted after GnuPG SmartCard pulled from reader

[gnupg-users . dirk]

Hi Andrew,

thanks for you input. And I will gave it a try.

1) deactivated my script
2) added udev rule ACTION=="add", SUBSYSTEM=="usb",
ATTR{idVendor}=="076b", ATTR{idProduct}=="3022", RUN+="/usr/sbin/service
pcscd restart"
3) testdrive - reader unplug - plug in (USB)

Jan 06 13:55:00 compd kernel: usb 1-5: USB disconnect, device number 7
Jan 06 13:55:00 compd systemd[1]: smartcard.target: Unit not needed
anymore. Stopping.
Jan 06 13:55:00 compd systemd[1]: Stopped target Smart Card.
Jan 06 13:55:00 compd pcscd[2532]:  ccid_usb.c:783:WriteUSB()
write failed (1/7): -4 LIBUSB_ERROR_NO_DEVICE
Jan 06 13:55:03 compd kernel: usb 1-5: new full-speed USB device number
8 using xhci_hcd
Jan 06 13:55:03 compd kernel: usb 1-5: New USB device found,
idVendor=076b, idProduct=3022
Jan 06 13:55:03 compd kernel: usb 1-5: New USB device strings: Mfr=1,
Product=2, SerialNumber=0
Jan 06 13:55:03 compd kernel: usb 1-5: Product: Smart Card Reader USB
Jan 06 13:55:03 compd kernel: usb 1-5: Manufacturer: OMNIKEY AG
Jan 06 13:55:03 compd mtp-probe[2713]: checking bus 1, device 8:
"/sys/devices/pci:00/:00:14.0/usb1/1-5"
Jan 06 13:55:03 compd mtp-probe[2713]: bus: 1, device: 8 was not an MTP
device
Jan 06 13:55:03 compd systemd[1]: Stopping PC/SC Smart Card Daemon...
Jan 06 13:55:03 compd systemd[1]: pcscd.service: Main process exited,
code=exited, status=1/FAILURE
Jan 06 13:55:03 compd systemd[1]: Stopped PC/SC Smart Card Daemon.
Jan 06 13:55:03 compd systemd[1]: pcscd.service: Unit entered failed state.
Jan 06 13:55:03 compd systemd[1]: pcscd.service: Failed with result
'exit-code'.
Jan 06 13:55:03 compd systemd[1]: Started PC/SC Smart Card Daemon.
Jan 06 13:55:03 compd systemd[1]: Reached target Smart Card.

=> works for replugging USB.

4) testrun without unpluging the reader only pulling the card from the
reader
dirk@compd:~$ gpg --card-status
gpg: selecting openpgp failed: No such device
gpg: OpenPGP card not available: No such device
dirk@compd:~$ gpg --card-status
gpg: selecting openpgp failed: No such device
gpg: OpenPGP card not available: No such device
dirk@compd:~$ gpg --card-status
gpg: selecting openpgp failed: No such device
gpg: OpenPGP card not available: No such device
dirk@compd:~$ gpg --card-status
gpg: selecting openpgp failed: Card error
gpg: OpenPGP card not available: Card error


=> no usb activty in syslog =>Failed

5)Works again

Your use case was you plugin the usb Card reader with a an ID-1 Card
(SIM). I have a fulle sized ID-000 card (Credit Card Size). I never
unplug the reader.


thanks
best regards Dirk

On 06.01.2017 12:23, Andrew Gallagher wrote:
> On 06/01/17 09:30, Kristian Fiskerstrand wrote:
>> On 01/06/2017 10:06 AM, gnupg-users.d...@o.banes.ch wrote:
>>> p.s. in the meantime a made a script which tails the scdaemon.log and
>>> waits for "Removal of a card:"
>>> and then kills the gpg-agent. Not a proper solution - but working so far.
>> Why not use udev rule to watch for removal event?
> Indeed.
>
> Dirk,
>
> I suspect you don't need to kill gpg-agent, just pcscd. I had to do the
> same thing when I used an ACS USB reader on my work laptop, because it
> already had a built in full-size reader that I couldn't use (I had
> already punched out the SIM) but which would override the (removable)
> USB reader because it was always found at startup.
>
> Put the following in /etc/udev/rules.d/99-local.rules (one line) :
>
> ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="072f",
> ATTR{idProduct}=="90cc", RUN+="/usr/sbin/service pcscd restart"
>
> You will need to change the idVendor and idProduct to match your
> hardware - these can be found using `lsusb` while the reader is plugged in.
>
> A
>
>
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Re: gpg-agent has to be restarted after GnuPG SmartCard pulled from reader

[gnupg-users . dirk]

Hi Kristian,

it is not the reader (USB Device) which is removed. It is the Card in
the reader.
I would not know how to monitor this with udev.  Is this possible ?

Best regards

Dirk

On 06.01.2017 10:30, Kristian Fiskerstrand wrote:
On 01/06/2017 10:06 AM, gnupg-users.d...@o.banes.ch wrote:
> p.s. in the meantime a made a script which tails the scdaemon.log and
> waits for "Removal of a card:"
> and then kills the gpg-agent. Not a proper solution - but working so far.
Why not use udev rule to watch for removal event?




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-agent has to be restarted after GnuPG SmartCard pulled from reader

[Andrew Gallagher]

On 06/01/17 09:30, Kristian Fiskerstrand wrote:
> On 01/06/2017 10:06 AM, gnupg-users.d...@o.banes.ch wrote:
>> p.s. in the meantime a made a script which tails the scdaemon.log and
>> waits for "Removal of a card:"
>> and then kills the gpg-agent. Not a proper solution - but working so far.
> 
> Why not use udev rule to watch for removal event?

Indeed.

Dirk,

I suspect you don't need to kill gpg-agent, just pcscd. I had to do the
same thing when I used an ACS USB reader on my work laptop, because it
already had a built in full-size reader that I couldn't use (I had
already punched out the SIM) but which would override the (removable)
USB reader because it was always found at startup.

Put the following in /etc/udev/rules.d/99-local.rules (one line) :

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="072f",
ATTR{idProduct}=="90cc", RUN+="/usr/sbin/service pcscd restart"

You will need to change the idVendor and idProduct to match your
hardware - these can be found using `lsusb` while the reader is plugged in.

A




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-agent has to be restarted after GnuPG SmartCard pulled from reader

[Kristian Fiskerstrand]

On 01/06/2017 10:06 AM, gnupg-users.d...@o.banes.ch wrote:
> p.s. in the meantime a made a script which tails the scdaemon.log and
> waits for "Removal of a card:"
> and then kills the gpg-agent. Not a proper solution - but working so far.

Why not use udev rule to watch for removal event?

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Dura necessitas
Necessity is harsh



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-agent has to be restarted after GnuPG SmartCard pulled from reader

[gnupg-users . dirk]

Hi Werner,

thanks for your reply.
I was under the impression the OmniKey 3121 is a real reader since it is
on the how to [1].

What would be a good alternative bevore I buy another bad one.

And I have problems understanding how the issue is connected to the key
length.

The Problem as I see it from user perspective:
Everything works fine with my 4096 RSA keys (agent, Card access,
en/decryption/authentication) until I pull the card.
When I insert it it again pcscd knows of it but the agent somehow does
not "retry".
I kill the agent (which also kills the scdaemon ) and then everything is
fine again.
Seems unrelated to key length since the general access does not work.

I'm happy to provide some logs.

best regards

Dirk

p.s. in the meantime a made a script which tails the scdaemon.log and
waits for "Removal of a card:"
and then kills the gpg-agent. Not a proper solution - but working so far.

[1] https://www.gnupg.org/howtos/card-howto/en/ch02s02.html

> Omnikey readers simply don't work correctly with 2k keys or larger.  Get
> a real reader and not that messy hardware which needs its proprietary
> Windows driver to work correctly which standard key lengths.
>
>
> Salam-Shalom,
>
>Werner
>



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-agent has to be restarted after GnuPG SmartCard pulled from reader

[Werner Koch]

On Wed,  4 Jan 2017 21:14, gnupg-users.d...@o.banes.ch said:

> thanks for you reply but it is now not working at all. Even if my reader
> - Ominkey 3121 is listed in you link.

Omnikey readers simply don't work correctly with 2k keys or larger.  Get
a real reader and not that messy hardware which needs its proprietary
Windows driver to work correctly which standard key lengths.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgptomdLDlQNi.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-agent has to be restarted after GnuPG SmartCard pulled from reader

[gnupg-users . dirk]

Hi Peter,

thanks for you reply but it is now not working at all. Even if my reader
- Ominkey 3121 is listed in you link.

o.k. I removed pcscd and changed the scdaemon.conf to this:
card-timeout 5
#disable-ccid
debug-level basic
log-file /home/dirk/scdaemon.log
debug-ccid-driver

scdaemon Log

2017-01-04 21:08:31 scdaemon[3398] listening on socket
'/run/user/1000/gnupg/S.scdaemon'
2017-01-04 21:08:31 scdaemon[3398] handler for fd -1 started
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver: using CCID reader 0
(ID=076B:3022:X:0)
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver: idVendor: 076B 
idProduct: 3022  bcdDevice: 0204
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver: ChipCard Interface
Descriptor:
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
bLength54
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
bDescriptorType33
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
bcdCCID  1.00
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
nMaxSlotIndex   0
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
bVoltageSupport 7  ?
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
dwProtocols 3  T=0 T=1
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
dwDefaultClock   4800
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
dwMaxiumumClock  8000
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
bNumClockSupported  4
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
dwDataRate  10752 bps
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
dwMaxDataRate  412903 bps
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
bNumDataRatesSupp.106
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
dwMaxIFSD 492
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:   dwSyncProtocols 
0007  2-wire 3-wire I2C
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:   dwMechanical

2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:   dwFeatures  
000407B2
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver: Auto
configuration based on ATR (assumes auto voltage)
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver: Auto clock change
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver: Auto baud rate
change
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver: Auto PPS made
by CCID
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver: CCID can set
ICC in clock stop mode
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver: NAD value other
than 0x00 accepted
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver: Auto IFSD exchange
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver: Short and
extended APDU level exchange
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
dwMaxCCIDMsgLen   502
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
bClassGetResponseecho
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
bClassEnvelope   echo
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
wlcdLayout   none
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
bPINSupport 0
2017-01-04 21:08:31 scdaemon[3398] DBG: ccid-driver:  
bMaxCCIDBusySlots   1
2017-01-04 21:08:36 scdaemon[3398] DBG: ccid-driver: usb_bulk_write
error: LIBUSB_ERROR_TIMEOUT
2017-01-04 21:08:36 scdaemon[3398] reader slot 0: using ccid driver
2017-01-04 21:08:36 scdaemon[3398] DBG: chan_5 -> OK GNU Privacy Guard's
Smartcard server ready
2017-01-04 21:08:41 scdaemon[3398] DBG: ccid-driver: usb_bulk_write
error: LIBUSB_ERROR_TIMEOUT
2017-01-04 21:08:41 scdaemon[3398] DBG: chan_5 <- GETINFO socket_name
2017-01-04 21:08:41 scdaemon[3398] DBG: chan_5 -> D
/run/user/1000/gnupg/S.scdaemon
2017-01-04 21:08:41 scdaemon[3398] DBG: chan_5 -> OK
2017-01-04 21:08:41 scdaemon[3398] DBG: chan_5 <- OPTION event-signal=12
2017-01-04 21:08:41 scdaemon[3398] DBG: chan_5 -> OK
2017-01-04 21:08:41 scdaemon[3398] DBG: chan_5 <- GETINFO version
2017-01-04 21:08:41 scdaemon[3398] DBG: chan_5 -> D 2.1.15
2017-01-04 21:08:41 scdaemon[3398] DBG: chan_5 -> OK
2017-01-04 21:08:41 scdaemon[3398] DBG: chan_5 <- SERIALNO openpgp
2017-01-04 21:08:46 scdaemon[3398] DBG: ccid-driver: usb_bulk_write
error: LIBUSB_ERROR_TIMEOUT
2017-01-04 21:08:46 scdaemon[3398] DBG: Removal of a card: 0
2017-01-04 21:08:46 scdaemon[3398] DBG: chan_5 -> ERR 100696144 No such
device 


On 04.01.2017 18:51, Peter Lebbing wrote:
> I think you should be able to use this card reader without pcscd, using the
> internal CCID driver of GnuPG[1]. Just stop and disable pcscd, hopefully GnuPG
> will find the reader and use it right away. That might solve your problem. I 
> use
> GnuPG's internal CCID driver, and it is completely resilient against both
> pulling the card as well as unplugging the reader.
>
> HTH,
>
> Peter.
>
> [1] https://www.gnupg.org/howtos/card-howto/en/ch02s02.html
>



___
Gnupg-users mailing list

Re: gpg-agent has to be restarted after GnuPG SmartCard pulled from reader

[Peter Lebbing]

I think you should be able to use this card reader without pcscd, using the
internal CCID driver of GnuPG[1]. Just stop and disable pcscd, hopefully GnuPG
will find the reader and use it right away. That might solve your problem. I use
GnuPG's internal CCID driver, and it is completely resilient against both
pulling the card as well as unplugging the reader.

HTH,

Peter.

[1] https://www.gnupg.org/howtos/card-howto/en/ch02s02.html

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

gpg-agent has to be restarted after GnuPG SmartCard pulled from reader

[gnupg-users . dirk]

Hello all,

I recently changed to the GnuPG Smartcard which in general works fine
for eMail and for SSH authentication (on Ubuntu 16.10).
The only problem I encountered was that when I pull the card from the
reader and reinsert it the gpg-agent will not recover.

I have to kill him gpgconf --kill gpg-agent.

I checked the logs for gpg-agent, scdaemon and pcscd.
The only suspicious I found was this in the pcscd output.

#normal operation

00500755 winscard_svc.c:353:ContextThread() Received command:
CMD_GET_READERS_STATE from client 14
00500775 winscard_svc.c:353:ContextThread() Received command:
CMD_GET_READERS_STATE from client 14
00500746 winscard_svc.c:353:ContextThread() Received command:
CMD_GET_READERS_STATE from client 14
00500754 winscard_svc.c:353:ContextThread() Received command:
CMD_GET_READERS_STATE from client 14

#remove card

00481042 eventhandler.c:357:EHStatusHandlerThread() Card Removed From
OMNIKEY AG 3121 USB 00 00
00019695 winscard_svc.c:353:ContextThread() Received command:
CMD_GET_READERS_STATE from client 14


#insert card

03660811 ifdhandler.c:1146:IFDHPowerICC() action: PowerUp,
usb:076b/3022:libudev:0:/dev/bus/usb/001/008 (lun: 0)
0032199 eventhandler.c:405:EHStatusHandlerThread() powerState:
POWER_STATE_POWERED
0025 eventhandler.c:422:EHStatusHandlerThread() Card inserted into
OMNIKEY AG 3121 USB 00 00
0013 Card ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00
90 00 0C

#query card

02063947 winscard_msg_srv.c:253:ProcessEventsServer() Common channel
packet arrival
0025 winscard_msg_srv.c:265:ProcessEventsServer()
ProcessCommonChannelRequest detects: 15
0007 pcscdaemon.c:134:SVCServiceRunLoop() A new context thread
creation is requested: 15
0093 winscard_svc.c:331:ContextThread() Authorized PC/SC client
0018 winscard_svc.c:335:ContextThread() Thread is started:
dwClientID=15, threadContext @0x9d5560
0019 winscard_svc.c:353:ContextThread() Received command:
CMD_VERSION from client 15
0009 winscard_svc.c:365:ContextThread() Client is protocol version 4:3
0006 winscard_svc.c:385:ContextThread() CMD_VERSION rv=0x0 for client 15
0083 winscard_svc.c:353:ContextThread() Received command:
ESTABLISH_CONTEXT from client 15
0014 winscard.c:215:SCardEstablishContext() Establishing Context:
0x5FFCC3AF
0005 winscard_svc.c:446:ContextThread() ESTABLISH_CONTEXT rv=0x0 for
client 15
0059 winscard_svc.c:353:ContextThread() Received command:
CMD_GET_READERS_STATE from client 15
0037 winscard_svc.c:353:ContextThread() Received command:
CMD_GET_READERS_STATE from client 15
0269 winscard_svc.c:353:ContextThread() Received command: CONNECT
from client 15
0035 winscard_svc.c:484:ContextThread() Authorized client for
'OMNIKEY AG 3121 USB 00 00'
0006 winscard.c:257:SCardConnect() Attempting Connect to OMNIKEY AG
3121 USB 00 00 using protocol: 3
0006 readerfactory.c:768:RFReaderInfo() RefReader() count was: 1

# Suspicious ?

0005 winscard.c:284:SCardConnect() Error Reader Exclusive

0004 winscard.c:512:SCardConnect() UnrefReader() count was: 2
0006 winscard_svc.c:498:ContextThread() CONNECT rv=0x801B for
client 15
02935987 ifdhandler.c:1146:IFDHPowerICC() action: PowerDown,
usb:076b/3022:libudev:0:/dev/bus/usb/001/008 (lun: 0)
0474 eventhandler.c:481:EHStatusHandlerThread() powerState:
POWER_STATE_UNPOWERED


I can not figure out what is the problem. Neiter I found anything in the
documentation / google . Is this  common ? 

Does anyone have an ideas where this problem comes from ?
Maybe it is just that I'm doing something wrong.
Happy to provide more information if needed.

thanks and best regards

Dirk




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users