René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"onlykey-agent fails after another app uses the OnlyKey","articleBody":"On Linux, `onlykey-agent` intermittently fails to open the OnlyKey's HID interface with a `OSError: open failed` error. It then works fine on the next invocation. \n\nThe issue can be reliably reproduced when the OnlyKey was just used by another application (e.g. KeePassXC HMAC-SHA1 challenge-response) or after a previous onlykey-agent run was interrupted with CTRL-C.\n\n## Environment\n\nArch Linux, [`hidapi`](https://archlinux.org/packages/extra/x86_64/hidapi/) with the [cython backend](https://github.com/trezor/cython-hidapi) resolving to `libusb` (`libhidapi-libusb`).\n\n```bash\n$ B=/home/fidel/.local/share/uv/tools/onlykey-agent/lib/python3.13/site-packages\n$ ldd \"$B/hid.cpython-313-x86_64-linux-gnu.so\"    | grep -i usb\n# uses libusb\nlibusb-1-150b88da.0.so.0.1.0 =\u003e /home/fidel/.local/share/uv/tools/onlykey-agent/lib/python3.13/site-packages/hidapi.libs/libusb-1-150b88da.0.so.0.1.0 (0x00007efee2c00000)\n$ ldd \"$B/hidraw.cpython-313-x86_64-linux-gnu.so\" | grep -i usb\n# no libusb\n```\n\n## Symptoms\n\n```\n# Do one of these things:\n# 1. Open a KeepassXC DB using Onlykey for HMAC\n# 2. Run `onlykey-agent` but abort with CTRL-C when seeing the button challenge.\n#    Then complete the challenge in OnlyKey and try onlykey-agent again.\n\n$ onlykey-agent \u003cidentity\u003e -- ssh \u003cserver\u003e\nERROR  failed to connect  [client.py]\nTraceback (most recent call last):\n  File \".../onlykey/client.py\", line ..., in _connect\n    self._hid.open_path(self.path)\n  File \"hid.pyx\", line 158, in hid.device.open_path\nOSError: open failed\n```\n\nRe-running the exact same command immediately afterward succeeds. Notably, waiting any amount of time does not help, only running the command a second time does.\n\n## The problem: libusb-backed hidapi\n\nOn my setup, `hid.enumerate()` returned `libusb`-style paths and zeroed usage pages:\n```\npath=b'1-3:1.2' usage_page=0x0 interface_number=2 ...\n```\n\nThe `hidraw` backend uses the device directly:\n```\npath=b'/dev/hidraw14' usage_page=0xf1d0 interface_number=2 ...\n```\n\nRunning `udevadm monitor --udev --subsystem-match=hidraw` when using the libusb-backed hidapi shows how the device id increments every time (0026, 0027, 0028...) as libusb detaches/reattaches the kernel driver:\n```\nUDEV  [6514.362533] remove   /devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:13:00.0/usb1/1-3/1-3:1.0/0003:1D50:60FC.0026/hidraw/hidraw12 (hidraw)\nUDEV  [6514.478417] add      /devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:13:00.0/usb1/1-3/1-3:1.0/0003:1D50:60FC.0027/hidraw/hidraw12 (hidraw)\nUDEV  [6515.641427] remove   /devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:13:00.0/usb1/1-3/1-3:1.0/0003:1D50:60FC.0027/hidraw/hidraw12 (hidraw)\nUDEV  [6515.980519] add      /devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:13:00.0/usb1/1-3/1-3:1.0/0003:1D50:60FC.0028/hidraw/hidraw12 (hidraw)\nUDEV  [6516.220419] remove   /devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:13:00.0/usb1/1-3/1-3:1.0/0003:1D50:60FC.0028/hidraw/hidraw12 (hidraw)\nUDEV  [6516.565550] add      /devices/pci0000:00/0000:00:02.1/0000:05:00.0/0000:06:0c.0/0000:13:00.0/usb1/1-3/1-3:1.0/0003:1D50:60FC.0029/hidraw/hidraw12 (hidraw)\n```\n\nUsing `hidraw` there is no detaching and reattaching.\n\n## Fix\n\nPrefer the `hidraw` backend on Linux, with a fallback to the current `hid` one. The change is minimal in *onlykey/client.py*. I will submit a PR with this fix.\n\nThe `hidraw` module exposes the same API, so no other code changes should be needed.","author":{"url":"https://github.com/haplo","@type":"Person","name":"haplo"},"datePublished":"2026-06-07T21:31:07.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/88/python-onlykey/issues/88"}