Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Power-cycling a key while the system is asleep breaks the connection #142

Closed
9ary opened this issue Apr 10, 2023 · 2 comments
Closed

Power-cycling a key while the system is asleep breaks the connection #142

9ary opened this issue Apr 10, 2023 · 2 comments

Comments

@9ary
Copy link

9ary commented Apr 10, 2023

I initially ran into this because I've disabled always-on USB on my laptop.

Using up to date Arch Linux, yubikey-agent 0.1.6, pcsclite 1.9.9.

Steps to reproduce:

  • establish a yubikey connection (by using the agent normally)
  • put computer to sleep
  • unplug key
  • plug it back into the same port
  • wake computer
  • try to use agent again

At this point, yubikey-agent fails to reconnect to the key. I see log messages such as could not reach YubiKey: selecting piv applet: command failed: transmitting request: an attempt was made to end a non-existent transaction and could not reach YubiKey: connecting to smart card: the smart card cannot be accessed because of other connections outstanding.

I can fix it by unplugging the key and plugging it back in again, or restarting either yubikey-agent or pcscd.

Moving the key to a different USB port or waiting for the computer to be awake doesn't trigger the problem.

I'm not ruling out the possibility of this being a pcscd bug, but maybe yubikey-agent is not handling something that it should somewhere along the way? Something noteworthy though is that in the case that breaks, the monitor example from yubikey.rs does not see any events.

@9ary
Copy link
Author

9ary commented Apr 11, 2023

I just tested for fun, and it looks like replacing the yubikey with a different one while the system is asleep also causes the exact same behavior.

Also looks like the kernel only sees a device reset, rather than a new device. I see these messages in dmesg:

[  +0.233951] usb 1-2: reset full-speed USB device number 62 using xhci_hcd

and

[  +0.351115] usb 1-2: usbfs: process 252659 (pcscd) did not claim interface 1 before use

This is starting to look like a pcscd bug. I'll take this upstream.

@9ary
Copy link
Author

9ary commented Apr 14, 2023

With LudovicRousseau/CCID@f3d3b86, this should now be fixed.

@9ary 9ary closed this as completed Apr 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant