Page MenuHome GnuPG
Create Task
Maniphest T4616

Smartcard: Card reset required - It should be automatic
Closed, ResolvedPublic
Actions

Description

I just wanted to create an issue for the problem I mentioned in chat.

It worked for me that my GNUK token survived "systemctl suspend". I could just use it afterwards.
With my OpenPGP 2.1 card in the SPR-532 that never worked. There was always the error "Card reset required".

Now my "Bug" report is: When "card reset required" shows up as an error. I can kill scdaemon and then it works again. So if I can fix it by killing scdaemon it should be possible that we can fix this state by itself. For me it seems like a software error which we can solve.
This might be a systematic problem so I am very fine if you put it on low priority. Personally it does not have high priority for me. I'm used to it. I just wanted to document it.

If you cannot reproduce this issue (as I partly understood from your chat) I can of course create logs.

Details

Version
master and 2.2

Revisions and Commits

rG GnuPG
rG165312dca90a scd: ccid-driver: Initial getting ATR more robustly.
rGc51a5685554a scd: ccid-driver: Initial getting ATR more robustly.

Related Objects

Event Timeline

• aheinecke created this task.Jul 8 2019, 2:30 PM
• gniibe added a comment.Jul 9 2019, 2:53 AM

Here are results of my experiment with Intel NUC computer (which supports S4 (and S3)).

(1) Old Gnuk Token (no support of USB suspend)

  • USB Power is kept supplied (LED keeps blinking)
  • works after resume

(2) Newer Gnuk Token (with support of USB suspend)

  • USB Power is suspended
  • works after resume

(3) TTXS (no support of USB suspend)

  • USB power is kept
  • failure after resume

It seems that the ccid-driver's initialization procedure is not good. Let me see in detail.

• gniibe added a comment.Jul 9 2019, 3:07 AM

When the computer is going to suspend, the scdaemon receives a message from USB layer as the interrupt transfer is shutting down, then scdaemon considers it's removal of device/card.
But in case of suspend (and the device does not support USB suspend), USB port is kept with the power.
So, it keeps running actually.

After resume, when scdaemon does normal initailization procedure, TTXS fails, because the baud rate is already changed.

I'm going to fix ccid-driver for the initialization to be more robust.

• gniibe added a commit: rGc51a5685554a: scd: ccid-driver: Initial getting ATR more robustly..Jul 9 2019, 4:01 AM
• gniibe added a comment.Jul 9 2019, 4:02 AM

I pushed my change of rGc51a5685554a: scd: ccid-driver: Initial getting ATR more robustly..
With TTXS, scdaemon correctly recovers from the error.

Please test with your reader.

• gniibe added a commit: rG165312dca90a: scd: ccid-driver: Initial getting ATR more robustly..Oct 6 2020, 5:04 AM
• werner mentioned this in T5052: Release GnuPG 2.2.24.Nov 17 2020, 9:33 AM
• werner changed the task status from Open to Testing.Nov 17 2020, 11:32 AM
• gniibe closed this task as Resolved.Jan 28 2021, 3:13 AM