pcscd fails to read future yubikeys after removing a yubikey, until restarted #125
Comments
|
scdaemon is a process used by GnuPG. it is problematic. To fix the repeating log diff --git a/src/ifdhandler.c b/src/ifdhandler.c
index 54c647e..f320f13 100644
--- a/src/ifdhandler.c
+++ b/src/ifdhandler.c
@@ -1956,7 +1956,7 @@ EXTERNAL RESPONSECODE IFDHICCPresence(DWORD Lun)
if (IFD_NO_SUCH_DEVICE == return_value)
{
- return_value = IFD_ICC_NOT_PRESENT;
+ return_value = IFD_NO_SUCH_DEVICE;
goto end;
} |
|
Thanks a lot for the quick response! I'll report the scdaemon segfault to GnuPG as soon as they approve my account for reporting. If I really only needed use my Yubikey with GnuPG, which one of scdaemon or pcsc-lite would you recommend me to keep? Is there some fundamental difference in their implementations, or can one be considered a superior implementation? Also, am I correctly assuming that I need pcsc-lite if I wanted to use my yubikey with PAM? |
|
If you only need to use GnuPG I would suggest to remove the pcscd package (I don't know how pcsc-lite is packaged on Gentoo) or just disable it. I would say pcsc-lite is better but I am biased here :-) |
|
I've just noticed, that I already had |
|
Try the patch I proposed. Maybe scdaemon is innocent here. |
|
I've applied the patch and re-tested everything, unfortunately everything is exactly like before. I'm getting the scdaemon segfault on first The only actual difference I observed is that the logged message change slightly (after removing the yubikey): |
|
Info: Opened a related gnupg bug report (https://dev.gnupg.org/T5963) |
|
The patch I proposed will not solve the problem. You can ignore it. Your problem is similar to #57
And send me all the outputs? Can you also apply this patch and generate a new pcscd log diff --git a/src/hotplug_libudev.c b/src/hotplug_libudev.c
index 5048689..29c011f 100644
--- a/src/hotplug_libudev.c
+++ b/src/hotplug_libudev.c
@@ -343,7 +343,10 @@ static void HPRemoveDevice(struct udev_device *dev)
parent = udev_device_get_parent_with_subsystem_devtype(dev, "usb",
"usb_device");
if (!parent)
+ {
+ Log1(PCSC_LOG_ERROR, "USB Device parent is NULL.");
return;
+ }
devpath = udev_device_get_devnode(parent);
if (!devpath)
@@ -360,6 +363,7 @@ static void HPRemoveDevice(struct udev_device *dev)
return;
}
+ Log3(PCSC_LOG_INFO, "Removing: %s %s", devpath, sysname);
for (i=0; i<PCSCLITE_MAX_READERS_CONTEXTS; i++)
{
if (readerTracker[i].fullName && !strcmp(sysname, readerTracker[i].sysname)) |
|
In my gpg bug report i speculated it might have somethin to do with a disappearing usb host controller. Note sure if that's really the case though. Here are the requested [connect yubikey] [remove yubikey] Here's the new log from patched pcsc-lite (https://gist.github.com/oddlama/821cbc24763141927aeb1d452276a6ff) |
|
It is the same problem as in #57 It is confirmed by the new pcscd log you generated. Remove the previous patch and try this one (generate a new psccd log please): diff --git a/src/hotplug_libudev.c b/src/hotplug_libudev.c
index 5048689..3a3ad78 100644
--- a/src/hotplug_libudev.c
+++ b/src/hotplug_libudev.c
@@ -331,7 +331,7 @@ static LONG HPReadBundleValues(void)
static void HPRemoveDevice(struct udev_device *dev)
{
int i;
- const char *devpath;
+ const char *devpath = "[NULL]";
struct udev_device *parent;
const char *sysname;
@@ -342,16 +342,17 @@ static void HPRemoveDevice(struct udev_device *dev)
tree, but the function will find it.*/
parent = udev_device_get_parent_with_subsystem_devtype(dev, "usb",
"usb_device");
- if (!parent)
- return;
-
- devpath = udev_device_get_devnode(parent);
- if (!devpath)
+ if (parent)
{
- /* the device disapeared? */
- Log1(PCSC_LOG_ERROR, "udev_device_get_devnode() failed");
- return;
+ devpath = udev_device_get_devnode(parent);
+ if (!devpath)
+ {
+ /* the device disapeared? */
+ Log1(PCSC_LOG_ERROR, "udev_device_get_devnode() failed");
+ }
}
+ else
+ Log1(PCSC_LOG_ERROR, "USB Device parent is NULL.");
sysname = udev_device_get_sysname(dev);
if (!sysname)
@@ -360,6 +361,7 @@ static void HPRemoveDevice(struct udev_device *dev)
return;
}
+ Log3(PCSC_LOG_INFO, "Removing: %s %s", devpath, sysname);
for (i=0; i<PCSCLITE_MAX_READERS_CONTEXTS; i++)
{
if (readerTracker[i].fullName && !strcmp(sysname, readerTracker[i].sysname))With this patch the device should be removed even if the device parent (USB bus) is no more present. |
|
I've applied your new patch and generated a new pcscd log: https://gist.github.com/oddlama/860637c3fb01c04eb3f565e58f3a7286 (FYI: the general behavior is the same) |
|
Much better. The Yubikey device is correctly removed now: I see you inserted again the device. But adding the device failed because it is already in use: Maybe that is a side effect of scdaemon that also opened the device. I would suggest to remove (or disable scdaemon) and check this solved the problem when reconnecting. |
|
Scdaemon is disabled with disable-ccid in |
|
It should be disabled. But I suspect scdaemon is still accessing the token. |
|
Unfortunately my gpg bug report has not been answered yet. Maybe they face a related issue. Are you positive that pcscd is not involved anymore? |
|
The patch I pushed should fix the problem when you remove the token. Building gpg without USB support is a good idea. Tell me if you still have problems after that. |
|
I can confirm that re-inserting the yubikey is now working properly, thank you. Unfortunately, any time the yubikey is inserted, the first attempt to use it with gpg fails, any subsequent tries succeed. In the failure case, Yet, |
|
You can generate a pcscd log including a |
|
One more question: what is your computer brand & model? Or the mother board brand & model if it is a computer you made yourself? I would like to know why it failed only on some systems. For example I was not able to reproduce the problem with the Yubikey tokens I have. |
|
It's a AERO 15X (i7-8750H) laptop from 2017 or 2018. I have none of the issues on my desktop PC. It might have something to do with the fact that the only USB-C slot is a thunderbolt port. BIOS is up to date, never had issues before they started appearing around January 2022, yet I cannot remember the month with certainty. I didn't change anything about my system except for updating software. All logs that I made already follow the procedure outlined in the initial post, but to be certain I've created another one (https://gist.github.com/oddlama/60fbdf13245c568dfa84d15393652f2e). These were my actions:
The problem is 100% reproducible on this machine, so if you need any other information be sure to let me know. |
|
I've just noticed an additional issue, might be related. When I manually start pcscd as root, the above behavior occurs. But when pcscd is started as root by systemd automatically (when the yubikey is being plugged in), the card is never detected by EDIT: Found out that a gpg-agent running as root seems to interfere somehow. Killing it solves the inconsistency. Still strange. Related pcscd log here (https://gist.github.com/oddlama/1325c4f32d1f54827c75759e38f81dfc)
EDIT2: You might also be interested in my gnupg bug report. Meanwhile I have generated a valgrind report of the segfault, and right at the beginning it includes an issue seemingly in libpcsclite. Excerpt from https://dev.gnupg.org/T5963: |
|
I have not found any PC/SC issue in your logs. I will have a look at the problem with SCardListReaders reported by valgrind. |
|
Thanks a lot for all the help. I'll sort out the rest with the GnuPG folks. |
|
The problem with |
|
I saw no feedback on the gnupg-dev mailing list. |
Versions
Platform
Issue
I replug my yubikey, or wake my system from sleep (which reenumerates the USB device). Now I want to use it with gpg and for simplicity, we assume that I just want to execute
gpg --card-status.The yubikey is detected and read.
Generally, when I insert a yubikey and try to read it with
gpg --card-status, the first attempt ALWAYS fails. Regardless of the situation. The second try and all successive tries work exactly if pcscd was freshly restarted. If pcscd is already running and had seen a yubikey previously, it always fails until restarted.Here are the relevant syslogs for the described actions. At the end of this issue I have included a more detailed pcscd debug log. When I just plug-in the yubikey for the first time after a fresh system restart:
Afterwards, the first
gpg --card-statusfails and produces these additional logs (scdaemon segfault):And from then,
gpg --card-statusworks without producing additional logs.Now the more severe problem is that as soon as I remove my yubikey, future yubikeys are never detected. And from the point of removal onwards, libusb errors are periodically written to the syslog. These errors continue for 1 minute, until systemd deactivates pcscd. This also temporarily resolves the issue, as pcscd is then restarted when plugging in a yubikey again.
No, I have confirmed this issue both with a different yubikey and on a fresh install of my distribution.
Log
(https://gist.githubusercontent.com/oddlama/59e90fc6ad47a8069180a69d94fe095c/raw/1f7da7963220040eae3bbf278164e46a934f123a/log.txt)
I have generated a debug log as requested. The exact actions I did while pcscd was logging are the following:
gpg --card-status(fails)gpg --card-status(succeeds)gpg --card-statusthree times with short waiting time in-between, but all fail.EDIT: It should be noted, that all
gpg --card-statuscommands were executed as an unprivileged user with access to the yubikey usb device (granted via udev). If using root, the first attempt also fails but other attemps succeed. Not sure whether gpg uses the integrated scdaemon as a fallback for the root user.The text was updated successfully, but these errors were encountered: