Wed, Jan 23
Thank you. I was waiting your feedback.
Tue, Jan 22
I can confirm this has the desired effect for me on master (f97dc55ff1b041071bc3cbe98aa761bf77bb7ac8). Should we mark this issue as 'resolved' or do you have another process for that?
Jan 17 2019
Jan 7 2019
Thanks a lot for your logs. I see what's going on here.
For some reason, Yubikey keeps running after failure by suspend/resume (perhaps, because it serves for multiple functionalities of USB HID for OTP, as well as CCID for OpenPGPcard).
This failure mode is not expected by the current implementation of scdaemon, under in-stock CCID driver.
Jan 4 2019
Attached the wireshark log
The workaround in T3825 is for PC/SC driver. So, it is not the case for internal stock CCID driver.
'scd reset /bye' does not let the scdaemon do reset process of the card itself. It resets the transaction of scdaemon.
Jan 3 2019
May 17 2018
Apr 11 2018
Workaround is implemented in 2.2.6.
Apr 5 2018
Mar 28 2018
Mar 13 2018
I've contacted Yubico to review this ticket.
Hi, that works as advertised. If this is the best solution yubikey permits us I am ok with it.
I put an entry: https://wiki.gnupg.org/SmartCard#Known_problem_of_Yubikey
After resume, because resume is not detected, some user interaction is required to cause an error.
gpg --card-status (which will only show partial information) is enough. Or, ssh failure. After failure, scdaemon reconnects the token.
Then, you can use it again without plug-off/plug-in.
Thanks a lot for pointers and suggestion.
Well, the problem of Yubikey itself cannot be solved by others, we can put some workaround for the error recovery.
So, this is another try of mine to improve error recovery.
Mar 12 2018
- There was same problem in yubico-piv-tool and it was solved by detecting error state (0x80100068) and reconnecting to the smart card if necessary 
- There is also a thread in OpenSC discussing this issue  and relevant PRs 
- I also found a project that claims to fix SCARD_W_RESET_CARD by disabling exclusive access to the card before asking for PIN (and then they enable exclusive access again) 
Part of the problem is Yubikey side, I suppose. (Because my implementation of Gnuk Token has no problem for suspend/resume if it's in-use.)
Again, thanks a lot for your testing. The log said: The code I added cannot detect the event of suspend/resume.
It seems that there is no way to recover from suspend/resume for Yubikey.
Mar 9 2018
Yeah, this is better, we got apdu_get_status => sw=0x0 status=7 and I can auth with this version as usual. After sleep-wake cycle it would however fail with pcsc_transmit failed: reset card (0x80100068). Logs attached.
Thanks a lot for your testing. So, apparently, the PC/SC behavior is different between GNU/Linux and Windows.
Thus, I pushed another change: rG1e27c0e04cd3: scd: More fix with PC/SC for Windows.. Please test this. (Both of previous version and this version work well on GNU/Linux for operations not including suspend/resume with Yubikey and Gnuk Token, while my Yubikey with PC/SC doesn't work well for suspend/resume.)
Mar 8 2018
Thanks, this version of scdaemon executes.
Sorry, my build was not good even if it's for x86_64 (I used development version of libassuan, etc.).
Mar 6 2018
@gniibe it seems the patched scdaemon.exe is 64 bit executable and it requires libassuan6-0.dll. However I got installed 32 bit version of gpg that only has incompatible libassuan-0.dll. I scanned whole computer for the missing lib, skimmed your ftp for 64 bit binaries and looked into gpg4win installer to find it, but no luck. There is also libassuan github repo, but I would like to avoid building the dll myself; there would probably be more than one dll to build anyway.
If possible, please try with this (patched version of scdaemon):
I realized that suspend/resume is not supported yet on GNU/Linux: https://anonscm.debian.org/cgit/pcsclite/PCSC.git/tree/TODO#n7
So, I can't test myself.
Here is an attempt to improve:
The reference is: https://stackoverflow.com/questions/11294638/how-to-use-scardgetstatuschange-correctly-on-windows-8
It looks like SCardGetStatusChange doesn't return failure after wake up.
Here, what we need is catching the event of wake up, which requires reset of the card.
I think that we can check by the dwEventState field.
I'll try on GNU/Linux environment, then ask you to try.
Mar 5 2018
@werner there had to be some mix up, as the log snippet is not mine.
This seems to be the relevant part of the log:
2017-11-18 07:45:15 scdaemon DBG: ccid-driver: CCID: card inactive/removed 2017-11-18 07:45:15 scdaemon ccid open error: skip 2017-11-18 07:45:15 scdaemon pcsc_establish_context failed: no service (0x8010001d) 2017-11-18 07:45:15 scdaemon DBG: ccid-driver: CCID: interrupt callback 0 2017-11-18 07:45:15 scdaemon DBG: ccid-driver: CCID: card removed