Yubico Forum

When I try to run a command like

I always get a USB-error:

Any hints?

Hi! Thanks for testing this code! I don't think many people have tested it, so we appreciate feedback here. I think the problem you ran into is a device ownership problem which we know how to work around, please see:

http://code.google.com/p/yubikey-core/s ... rounds.txt

If you or someone else understands why this is needed, explaining that further would be appreciated.

Thanks,
Simon

While I'm not an expert in USB device programming, I feel that I have a fair understanding of what's going on here. I have been working on a native OS X version of the personalization tool (which uses libusb in its current state), and had similar issues with the app in my environment.

What happens here is that Linux, just like OS X, has a USB HID layer built in to the OS. When you connect something that states that it's a HID device, for example a keyboard or a Yubikey, the OS will recognize it as such and the HID layer will take control over the device. Both OS X and Linux takes exclusive control over the device, which means that any other application that tries to open the device will receive a message that the device is busy.

Now, I am assuming that the workaround in that document tells the HID layer of Linux to not bother taking control over the Yubikey. This results in two things: First, the HID layer will not lock the device which is good considering the personalization tool will now be able to open it. Second, the Yubikey will no longer be considered a keyboard by the operating system, but act as a generic USB device. This, of course, makes it impossible for the key to output any password. So you're left with being forced to reload the hid module without the quirks mode on the Yubikey.

Now, the OS X kernel doesn't have a quirks mode like this, so I was out of luck there. Instead, I modified the code to not bother opening the Yubikey, which worked.. However, that's strictly against all documentation of how you're supposed to work with USB devices so I wasn't very satisfied with that solution.

So, that left me with one option: Work with the OS rather than trying to force my way through. I dove into some documentation and found that OS X 10.5.5 (Leopard) included some new API for working with HID devices (lucky me!). So after some work, I've managed to implement a native OS X backend for the personalization tool. This backend replaces the libusb backend that's in the personalization tool as I write this, and is fully functional on my own system.

The main problem with the personalization tool is quite simply that it tries to force its way into the Yubikey while it's being detected as a keyboard (and locked in exclusive access mode) by the host OS. While this seems to work fine under Windows, both Linux and OS X will complain similarly to what you've been seeing. To me, the correct way to get past this awkward workaround is to find out how an application can communicate with the Yubikey through the HID layer of the Linux kernel rather than brute-forcing its way to the USB device. Ideally, a project like libusb but targetted at the hid layers of the various operating systems would be great, but I haven't been able to find anything like it. (Note that there is a project called libhid which seems to be trying that, but they seem to be using libusb to get to the hardware rather than the real native HID APIs of the various host OSes).

But as I said, I'm not an expert USB programmer, so some of these details may be wrong.

Thanks! The hint works perfectly. I think I might write a small wrapper script along the lines:




Actually I think the text describes the problem rather accurately...

I get the same USB error. I have tried this workaround, on both Fedora 10 and CentOS 5, and the modprobe command comes back with:

FATAL: Module usbhid not found.

Interesting, I have heard that some redhat variations don't use a module for usbhid. Can you show us the output from the 'lsmod' command?

Maybe you need to supply the parameters as kernel parameters when doing personalization.

Exploring whether using libhid rather than libusb would solve this problem looks more important now.

/Simon

Maybe I would be seen as a Troll as I'm a Windows guy, but please be gentle to an old man. Just some reflections that hopefully can add something.

Interestingly enough, it seems like HID keyboards and mice are exclusively acquired by the operating system. In Windows (Win32) however, it seems like they are not exclusively acquired and such devices are okay to open if the access mode is set to "shared". I don't know if something like that could be applied to the LibUSB/Linux implementation.

The HID layer is built entirely on top of the USB stack and I cannot really see that such a "wrapper" could make a difference. The only HID functions needed to communicate with the Yubikey is the set and get feature class specific control transfers.

I played around with the LibUSB Win32 some time ago, and the only low-level functions that I had to implement were these.

int hidGetReport(YUBIKEY yk, int reportType, int reportNumber, char *buffer, int size)
{
return usb_control_msg(yk, USB_TYPE_CLASS | USB_RECIP_INTERFACE | USB_ENDPOINT_IN, HID_GET_REPORT,
reportType << 8 | reportNumber, 0, buffer, size, 1000) > 0;
}

int hidSetReport(YUBIKEY yk, int reportType, int reportNumber, char *buffer, int size)
{
return usb_control_msg(yk, USB_TYPE_CLASS | USB_RECIP_INTERFACE | USB_ENDPOINT_OUT, HID_SET_REPORT,
reportType << 8 | reportNumber, 0, buffer, size, 1000) > 0;
}

I guess there are utility applets around that lights up the CapsLock/NumLock/ScrollLock buttons. These apps must face the same problem as these requests use the same mechanism. Anyone seen anything like that ? For Windows, it seems like there are a few.

Regards,

JakobE
Hardware- and firmware guy @ Yubico

Simon wrote:

> Interesting, I have heard that some redhat variations don't use a module for usbhid. Can you show us the output from the 'lsmod' command?

OK, here it is, for my Fedora 10 workstation. I do have a flash drive plugged in (so usb_storage is loaded) and I am running VMware Workstation. However, nothing changes if I remove the flash drive and unload usb_storage and/or if I shut down VMware and unload all the vm* modules. The same problem also occurs on a CentOS box that has none of this extra baggage. Also, the lsmod output is the same whether or not the Yubikey is plugged in.

usb_storage 86408 1
vmnet 37804 15
parport_pc 25620 0
vmblock 15780 3
vmci 46116 1
vmmon 63372 7
nfs 218296 1
lockd 57720 1 nfs
nfs_acl 6656 1 nfs
ext2 58760 1
vfat 12672 1
fat 42784 1 vfat
fuse 49436 2
bridge 43668 0
stp 6148 1 bridge
bnep 14848 2
sco 12932 2
l2cap 21504 3 bnep
bluetooth 48608 5 bnep,sco,l2cap
autofs4 21124 5
sunrpc 156052 11 nfs,lockd,nfs_acl
ip6t_REJECT 7296 2
nf_conntrack_ipv6 15864 4
ip6table_filter 6400 1
ip6_tables 14736 1 ip6table_filter
ipv6 230260 50 ip6t_REJECT,nf_conntrack_ipv6
cpufreq_ondemand 9996 2
acpi_cpufreq 12172 0
dm_multipath 17164 0
uinput 10624 0
snd_hda_intel 353812 3
snd_seq_dummy 6660 0
snd_seq_oss 30364 0
snd_seq_midi_event 9600 1 snd_seq_oss
snd_seq 48576 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device 10124 3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss 42496 0
tg3 107524 0
snd_mixer_oss 16896 1 snd_pcm_oss
snd_pcm 65924 2 snd_hda_intel,snd_pcm_oss
snd_timer 22024 2 snd_seq,snd_pcm
snd_page_alloc 11144 2 snd_hda_intel,snd_pcm
iTCO_wdt 13732 0
iTCO_vendor_support 6916 1 iTCO_wdt
libphy 18560 1 tg3


> Maybe you need to supply the parameters as kernel parameters when doing personalization.

That's a workable option if I knew exactly what arguments to supply in grub.conf. In any case, we could work around this easily enough. We have a separate workstation that will be used for token initializations, and we could easily just run Ubuntu on it, which we know from other testing does have usbhid as a module.


> Exploring whether using libhid rather than libusb would solve this problem looks more important now.

It would certainly make things less kludgy if it worked.

The rmmod/modprobe technique will no work if the usbhid module is compiled into the kernel, in such case the /sys files can be used (at least with kernels > 2.6.20):

To replicate the quirks workaround:
as root:
echo -n 0x1050:0x0010:0x04 > /sys/module/usbhid/parameters/quirks (although it did not work for me - probably a different format of 0x1050:0x0010:0x04 is needed )
or unbind the device:
/sys/module/usbhid/drivers/usb:usbhid - check the devices listed there, unplug YK, and check which device was removed, then plug the YK once more, and:
echo -n YK_device > /sys/module/usbhid/drivers/usb:usbhid/unbind

Hope this helps.

Piper wrote:

> To replicate the quirks workaround:
> as root:
> echo -n 0x1050:0x0010:0x04 > /sys/module/usbhid/parameters/quirks (although it did not work for me - probably a different format of
> 0x1050:0x0010:0x04 is needed )

It didn't work for me either. Has anybody figured out the exact format needed for this on Fedora 11, 2.6.29.4-167.fc11.i686.PAE

We can probably work around this by using an Ubuntu box for our development workstation, as Ubuntu appears to ship usbhid as a module so it can be loaded with parameters, but the above would be a lot easier for us if we can make it work.