Smartcard access may fail with error "Invalid Value" after resuming system from suspend
Closed, ResolvedPublic

Description

With GnuPG master (2.1.21-beta7) on debian jessie I sometimes (happened now for the second time) can't sign / authenticate after waking my system from sleep (suspend to ram). Because the operation fails with the unhelpful error message "Invalid value". Only killing scdaemon resolves the issue.

The debug output is

The Smartcard I was trying to access was a GNUK Token.

aheinecke created this object in space S1 Public.
gniibe triaged this task as Normal priority.Apr 11 2017, 1:32 PM
gniibe edited projects, added scd, gnupg (gpg21); removed gnupg.

It looks like the device got suspended and resumed.
But the application (scdaemon) didn't get noticed by libusb.
So, scdaemon kept communicating as usual, but got unexpected msg type = 0x81,
which is error report status (RDR_to_PC_DataBlock).

This unexpected error report should be handled correctly, at least.

By the commit: rGf053f99ed0b0: scd: Handle unexpected suspend/resume by CCID driver., I put some code to handle such an expected return from the device.
Please try.
I couldn't reproduce this on my machine. (Suspend-to-RAM keeps my USB device running.)

werner moved this task from gpg21 to gpg22 on the gnupg board.Oct 20 2017, 1:56 PM
werner edited projects, added gnupg (gpg22); removed gnupg (gpg21).
werner edited projects, added Testing; removed In Progress.Oct 24 2017, 12:23 PM
gniibe added a comment.EditedNov 29 2017, 7:18 AM

I learned suspend-to-ram functionality. Currently, for Linux, if we have USB driver in kernel, there are methods to handle suspend-to-ram and resume events. For user space driver by libusb, there is nothing and it should all work well by reseting after resume.

There is nothing we can do by scdaemon.
So, closing.

gniibe closed this task as Resolved.Nov 29 2017, 8:20 AM

If more fine-grained control is needed with suspend-to-ram, we need to write kernel driver for USB access.