Yubikey 5c Reader "stuck" #57
Comments
|
CCID Driver version: 1.4.30 Hardware: Lenovo Thinkpad T470s Card/reader: Yubikey 5C, Firmware version 5.1.2 Full log: Initial state: pcscd not running, yubikey not plugged in
|
|
Minor update: Yubikey Neo (USB-A) behaves the exact same way if connected via a USB-C adapter, but only if the connection is changed at the USB-C end. If the USB-A portion is connected/disconnected, it behaves as expected. Maybe some USB-C hotplug issue? |
|
What is very strange is that your device is always at /dev/bus/usb/003/002 even after a unplug + replug. The last number should always increase for new USB device. Try this:
Send me the results of the 3 |
|
lsusb: Also, just for fun: |
|
The device number should increase for any new USB device. As I wrote I suspect a problem with USB-C in the Linux kernel. Or maybe your PC firmware. |
Is that also the case when the USB device is connected to a PCI USB controller that's also getting connected/disconnected? Because that's how my USB-C devices seem to behave - both my Yubikey 5C and my C-to-A adapter. |
|
I checked with my Yubikey 4 OTP+U2F+CCID on a USB-C port. Second connection: The Device number changed from 5 to 6. From your kernel log file I do not like the lines: |
|
They Yubikey 4 is a USB-A device, correct? So you're using a USB-C adapter? What connection are you actually changing? If it's the Yubikey-Adapter connection, then my Neo behaves the same way. It's when the adapter (which shows up as a PCI USB controller) is unplugged that the bus itself goes away and all device numbers start back at 1 when it's plugged back in. Is that expected behavior? |
|
Oh, I see that there is a Yubikey 4C. If that's the case, is it possible that it's using the legacy USB-C configuration and not acting as a PCI USB controller like the 5C is? |
|
Apply this patch: --- /tmp/sn6adU_hotplug_libudev.c 2019-03-10 22:16:19.624623740 +0100
+++ src/hotplug_libudev.c 2019-03-10 22:16:18.312607387 +0100
@@ -359,6 +359,7 @@ static void HPRemoveDevice(struct udev_d
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))Generate a new pcscd log with inserting and removing your device.. |
|
New log: log.txt However, it's never actually getting to the point where it hits that log message. It's returning from if (!parent)
return;Patch w/ log invocation: diff --git a/src/hotplug_libudev.c b/src/hotplug_libudev.c
index 25bd408..505b6c3 100644
--- a/src/hotplug_libudev.c
+++ b/src/hotplug_libudev.c
@@ -341,8 +341,10 @@ 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)
+ if (!parent) {
+ Log1(PCSC_LOG_INFO, "USB Device parent is NULL.");
return;
+ }
devpath = udev_device_get_devnode(parent);
if (!devpath)
@@ -359,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))Resulting log: |
|
Very interesting. I think you found the cause of issue. I will try to contact Yubico to get a yubikey 5c so I can debug on my side. |
|
It is strange that 2 new USB bus are created when you connect the Yubikey device: The Yubikey then appears on bus 003
|
|
I got a YubiKey 5C. I can't reproduce your problem. With the YubiKey: Note that the YubiKey is connected to Bus 001. This USB bus was already existing. And will still exist after I remove the key. Maybe you can configure your BIOS/UEFI to change the configuration of your USB-C port on the mother board? |
|
Any progress on this issue? |
|
I had similar issue after updating to Fedora 30. With Fedora 29 everything works well. I use Yubikey 4 and Yubikey 5 NFC. Unplugging: 01000595 ccid_usb.c:857:WriteUSB() write failed (1/10): -4 LIBUSB_ERROR_NO_DEVICEPlugging: 00822239 ifdhandler.c:150:CreateChannelByNameOrChannel() failed
00000011 readerfactory.c:1105:RFInitializeReader() Open Port 0x200000 Failed (usb:1050/0407:libudev:0:/dev/bus/usb/001/011)
00000002 readerfactory.c:376:RFAddReader() Yubico YubiKey OTP+FIDO+CCID init failed.
00026929 ifdhandler.c:150:CreateChannelByNameOrChannel() failed
00000008 readerfactory.c:1105:RFInitializeReader() Open Port 0x200001 Failed (usb:1050/0407:libudev:1:/dev/bus/usb/001/011)
00000002 readerfactory.c:376:RFAddReader() Yubico YubiKey OTP+FIDO+CCID init failed.
$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
Bus 001 Device 003: ID 05ac:0256 Apple, Inc. USB DEVICE
Bus 001 Device 011: ID 1050:0407 Yubico.com Yubikey 4 OTP+U2F+CCID
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
Bus 001 Device 003: ID 05ac:0256 Apple, Inc. USB DEVICE
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
Bus 001 Device 003: ID 05ac:0256 Apple, Inc. USB DEVICE
Bus 001 Device 012: ID 1050:0407 Yubico.com Yubikey 4 OTP+U2F+CCID
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub |
|
Hi, sorry for the long silence. I changed jobs shortly after submitting this issue and got a new computer that didn't exhibit the problematic behavior. That said,
I did play briefly with the "Thunderbolt BIOS Assist" setting on my old laptop, and setting it one way (can't remember which 😕) made the problem go away. I've been hesitant to mess with it on my new computer after seeing reports of bricking after changing it. I'm not entirely clear on what the setting actually does or what its trade-offs are. |
|
@L11r I think your problem is different. |
|
The problem was a BIOS/UEFI feature/bug issue. |
|
I have this same issue on Ubuntu 20.04. Is there some way I can make pcscd ignore the yubikey? I don't intend to use it as a smart card but I need pcscd for a different reader and would love if I could get pcscd to stop filling up my syslog. |
|
@daveman1010221 have you tried to upgrade your computer BIOS? |
|
You can also ignore a reader. See https://ludovicrousseau.blogspot.com/2015/12/remove-andor-customize-pcsc-reader-names.html |
|
I attempted to ignore the reader, using the method "left as an exercise to the reader" for systemd. This was my result: Other info: |
|
You need to rebuild pcsc-lite. |
|
libpcsclite-dev is what I have installed on Ubuntu. Is this what you mean to rebuild? |
|
No. Get the source code and rebuild the software. |
|
Ok, I can build it from source. Just wanted to confirm you meant only the library, not the daemon? |
|
@jrobsonchase @L11r @daveman1010221 I fixed this bug in a3e09df You can also reader issue #125 |
PCSC Version: 1.8.24
OS: Arch Linux
For some reason, I can only seem to get my yubikey 5c to be picked up by pcscd once. When it's plugged in after a fresh restart of pcscd, the reader and card show up as expected in pcsc_scan. When it's unplugged, the pcscd log is filled with
and the reader sticks around in pcsc_scan with a "status unavailable" card state.
When re-plugging it in, I get
and the reader state in pcsc_scan doesn't change.
Re-starting pcscd allows the reader and card to both be picked back up.
In contrast, my several-years-old Yubikey Neo (USB-A) connects and disconnects just fine - both card and reader disappear and re-appear when it's unplugged and plugged back in.
The text was updated successfully, but these errors were encountered: