USB device support, libusb (ADB support, etc)

[timcanham]

This bug-tracker is monitored by developers and other technical types. We like detail! So please use this form and tell us, concisely but precisely, what's up. Please fill out ALL THE FIELDS!

If you have a feature request, please post to the UserVoice. If you're reporting a BSOD, don't post here! Instead, e-mail "secure@microsoft.com", and if possible attach the minidump from "C:\Windows\minidump".

• Your Windows build number: Microsoft Windows [Version 10.0.14393]

• What you're doing and what's happening: Trying to use the adb package to talk to embedded boards via USB. Used apt-get to install it.

• What's wrong / what should be happening instead: The adb utility finds no devices.

• Strace of the failing command, if applicable: (If <cmd> is failing, then run strace -o strace.txt -ff <cmd>, and post the strace.txt output here)

n/a

See our contributing instructions for assistance.

[timcanham]

Perhaps related to #825.

[sunjoong]

@timcanham - I'm not sure but... ethanhs/WSL-Programs#29 and the first raw of list in https://github.com/ethanhs/WSL-Programs .

[timcanham]

The image they showed seemed to indicate it work in cmd.exe but not bash.

[sunjoong]

@timcanham - Commands that begin with bash -c were bash command after bash -c; You could command ls in bash but could bash -c ls in cmd.exe. And... yeah... it shows WSL partially suport ADB; the list said you need ADB in windows too especially for USB devices, you know.

[therealkenc]

libusb, lsusb and friends. The image shows adb installed but listing no devices (props to the adb devs for failing gracefully instead of faceplanting). It used to be this User Voice before it was closed. WSL also lacks udev atm.

[ReVanTis]

@sunjoong @timcanham
Please do read what I posted carefully ethanhs/WSL-Programs#29 (comment)
ADB is functional only when you start adb server in the host system(windows), thus host system would handle all usb traffic for bash on windows.
That's also why adb on both sides are required to be the very same version so they would recognize each other and communicate through tcp.
It's not natively supported by bash because usb is not generally working on bash.
In addition I assume adb over tcp/ip (adb connect [IP]) would work even with adb server started in bash.

[zoldyckw]

thanks @ReVanTis , now i can build rom for my xperia.... my adb now is showing my device...

[CyrilTaylor]

I test it in my PC, the version of adb in bash should be same as it in cmd, because if the version of adb client not match the version of adb server, the adb server will be killed by adb client in bash and restart adb server in bash, adb server in bash can't access the devices in windows. so there are steps to make sure adb work in bash:

1. there are same version of adb in bash and cmd.
2. start adb-server in cmd first, and make sure adb-server running in windows end.

[oldium]

As a workaround, you can install adb.exe on Windows and access it from Linux - just create a symbolic link from adb.exe to /home/<user>/bin/adb. Tested on the latest Insider Windows build (17063).

[tommai78101]

Even if you create a symbolic link from adb.exe to /usr/bin/adb (the path obtained after you do sudo apt-get install adb), you would still run into the issue where ADB cannot be found if you run python /android-sdk/platform-tools/systrace/systrace.py.

So technically speaking, the ADB is not the same as Windows ADB.

[kengkeelim]

@ReVanTis May I know how do you get to make both ADB in bash and cmd the same version? Thank you for your time.

[ReVanTis]

@kengkeelim Download here: https://developer.android.com/studio/releases/platform-tools
Download both Linux and Windows version and use them together.

[caver456]

Just a note, I was able to work for a couple weeks with windows adb version being newer and ubuntu-in-wsl adb version being older: I installed an older sdk for specific reasons, which had the older adb with it. Yes, each time I tried adb in one OS vs the other it would stop the different-version adb server and start the one for the current OS, and then it would recognize just fine. Tonight, for some reason that I was not sharp enough to track down, it stopped in both OSes - after all the various fixes I could find for adb not recognizing the device, I finally tried installing the same adb version on linux as on windows (without affecting the older sdk I had previously installed). Now both OSes recognize the device, just like the good ol days.

[jan4984]

anyhow WSL-Programs will die because WSL 2 coming.

[WSLUser]

anyhow WSL-Programs will die because WSL 2 coming

WSL1 still lives and versions of Windows that only offer WSL1 still exist. So no it won't die for a long time.

[therealkenc]

#825 ended up being closed incorrectly conflating RS232 serial devices with USB. The User Voice for USB device support is here. [ed] Now LZ this issue since UserVoice is closed.

[Biswa96]

Some clarifications.

Actually it seems that the required WSL kernel update (5.10.60.1) is now offered at least for Windows 10 21H1

You don't have to wait for the update. It can be downloaded from here https://www.catalog.update.microsoft.com/Search.aspx?q=wsl or here https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi

because all WSL instances actually run as containers within the same Linux VM

Only the WSL2 instances are running in VM mode.

at the moment usbipd wsl attach works only when specifying a Debian/Ubuntu-based WSL instance

The usbip feature is not distribution specific.

[sigprof]

The usbip feature is not distribution specific.

The current release of usbipd-win has a compatibility problem which makes usbipd wsl attach work only when the Debian variant of the hostname utility is used by the specified WSL2 instance: dorssel/usbipd-win#85 (a fix is already in development though). In addition, there might be potential compatibility issues between the distro-provided usbip binary and the WSL2 kernel (but I did not notice anything like that in my testing).

[ghost]

Anything new here?

[matrixes]

You are now able to access USB devices from within WSL using a 3rd party workflow. For full details I recommend that you watch this YouTube video: https://www.youtube.com/watch?v=I2jOuLU4o8E

The summary is that the Visual Studio team contributed to an open source and 3rd party project called usbipd-win. Using this tool will now allow you to pretty easily access your USB devices from within WSL, on any Windows 11 machine.

I'm going to keep this issue open as we would still like to track having a USB solution that is directly part of WSL, but using this project should unblock many scenarios mentioned here.

Thank you!

usbipd-win is certainly a welcome alternative. I've been able to interface with e.g. an arduino using this method and it has its uses. One thing that I'd also like to get working is being able to use my Yubikey (4, if that's a useful detail) within WSL, accessible as a non superuser. There's some discussion about it here dorssel/usbipd-win#127 (comment) but the quote "...you will need to compile a kernel with the correct drivers, I think..." is where I'm stuck.

[dinvlad]

@matrixes for the Yubikey, I've been successfully using it without usbipd-win for signing and pushing commits and Webauth inside WSL in a multi-WSL-distro scenario. It's pretty useful to be able to share the same Yubikey between Win and WSL, and I'm not sure if usbipd-win actually enables that (is it exclusive to the guest?)

[beriberikix]

Did you follow everything here? https://support.yubico.com/hc/en-us/articles/360013708900-Using-Your-U2F-YubiKey-with-Linux. I don't know enough about the yubikey but I've seen a lot of people successfully use usbipd-win in the following scenarios:

• The device driver is already enabled or not needed, just need the proper udev rule (example)
• They needed to build a custom kernel and enable the right driver (see Enable common USB Serial devices by default #7686)
• They were missing some user-space dependency or linking to an old version (ex. libusb)

It's unclear how HID is supported or if it's needed for a Yubikey, so this may not be that helpful for you!

[dinvlad]

I haven't tried personally, as I've made it successfully and reproducibly work without usbipd-win and having to rebuild the kernel. Here's a guide I've composed on it from several other guides: https://gist.github.com/dinvlad/a62d44325fa2b989a046fe984a06e140

[matrixes]

Updated post

---

Did you follow everything here? https://support.yubico.com/hc/en-us/articles/360013708900-Using-Your-U2F-YubiKey-with-Linux. I don't know enough about the yubikey but I've seen a lot of people successfully use usbipd-win in the following scenarios:

* The device driver is already enabled or not needed, just need the proper udev rule ([example](https://github.com/Yubico/libu2f-host/blob/master/70-u2f.rules))

* They needed to build a custom kernel and enable the right driver (see [Enable common USB Serial devices by default #7686](https://github.com/microsoft/WSL/issues/7686))

* They were missing some user-space dependency or linking to an old version (ex. libusb)

It's unclear how HID is supported or if it's needed for a Yubikey, so this may not be that helpful for you!

I did not know of this, thanks for bringing it forward. I've followed the instructions (I enabled/included all USB devices/manufacturers I could find in the wsl-config interface) that are linked from #7686 and I'm unfortunately still not able to interact with the key as non-root. Here's the log up to this point.

Kernel before following instructions

$ uname -r
5.10.60.1-microsoft-standard-WSL2

Kernel after following instructions

$ uname -r
5.10.74.3-microsoft-standard-WSL2+

udev seems to find and attach the Yubikey properly

$ udevadm monitor
KERNEL[1353.300781] add      /devices/platform/vhci_hcd.0/usb1/1-1 (usb)
KERNEL[1353.305737] add      /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.0 (usb)
KERNEL[1353.309796] add      /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.0/0003:1050:0407.0009 (hid)
KERNEL[1353.309872] add      /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.0/0003:1050:0407.0009/input/input4 (input)
KERNEL[1353.371106] bind     /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.0/0003:1050:0407.0009 (hid)
KERNEL[1353.371156] bind     /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.0 (usb)
KERNEL[1353.371200] add      /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.1 (usb)
KERNEL[1353.374674] add      /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.1/0003:1050:0407.000A (hid)

lsusb sees it fine

$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 1050:0407 Yubico.com Yubikey 4 OTP+U2F+CCID
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

gpg does not recognise the device for my user

$ gpg --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

gpg recognises the device for root

$ sudo gpg --card-status
[sudo] password:
Reader ...........: Yubico YubiKey OTP FIDO CCID 00 00

I also tried this pointer dorssel/usbipd-win#127 (comment) without success

It certainly seems like all this is close to working, but I can't tell where the answer is, only conclude that my user does not recognise the device while root does.

I haven't tried personally, as I've made it successfully and reproducibly work without usbipd-win and having to rebuild the kernel. Here's a guide I've composed on it from several other guides: https://gist.github.com/dinvlad/a62d44325fa2b989a046fe984a06e140

I have a very similar setup from https://blog.nimamoh.net/yubi-key-gpg-wsl2/ but it's janky and I'd rather get something closer to scdaemon working properly/natively instead of passing messages between WSL to Gpg4Win through socat glue.

[onyxcherry]

I haven't tried personally, as I've made it successfully and reproducibly work without usbipd-win and having to rebuild the kernel. Here's a guide I've composed on it from several other guides: https://gist.github.com/dinvlad/a62d44325fa2b989a046fe984a06e140

Did you follow everything here? https://support.yubico.com/hc/en-us/articles/360013708900-Using-Your-U2F-YubiKey-with-Linux. I don't know enough about the yubikey but I've seen a lot of people successfully use usbipd-win in the following scenarios:

• The device driver is already enabled or not needed, just need the proper udev rule (example)
• They needed to build a custom kernel and enable the right driver (see Enable common USB Serial devices by default #7686)
• They were missing some user-space dependency or linking to an old version (ex. libusb)

It's unclear how HID is supported or if it's needed for a Yubikey, so this may not be that helpful for you!

Unfortunately, even with Yubico's udev rules - same as I wrote here #2195 (comment) :(

[SheepReaper]

Did you follow everything here? https://support.yubico.com/hc/en-us/articles/360013708900-Using-Your-U2F-YubiKey-with-Linux. I don't know enough about the yubikey but I've seen a lot of people successfully use usbipd-win in the following scenarios:

* The device driver is already enabled or not needed, just need the proper udev rule ([example](https://github.com/Yubico/libu2f-host/blob/master/70-u2f.rules))

* They needed to build a custom kernel and enable the right driver (see [Enable common USB Serial devices by default #7686](https://github.com/microsoft/WSL/issues/7686))

* They were missing some user-space dependency or linking to an old version (ex. libusb)

It's unclear how HID is supported or if it's needed for a Yubikey, so this may not be that helpful for you!

I did not know of this, thanks for bringing it forward. I've followed the instructions (I enabled/included all USB devices/manufacturers I could find in the wsl-config interface) that are linked from #7686 and I'm unfortunately still not able to interact with the key as non-root. Here's the log up to this point.

Kernel before following instructions

$ uname -r
5.10.60.1-microsoft-standard-WSL2

Kernel after following instructions

$ uname -r
5.10.74.3-microsoft-standard-WSL2+

udev seems to find and attach the Yubikey properly

$ udevadm monitor
KERNEL[1353.300781] add      /devices/platform/vhci_hcd.0/usb1/1-1 (usb)
KERNEL[1353.305737] add      /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.0 (usb)
KERNEL[1353.309796] add      /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.0/0003:1050:0407.0009 (hid)
KERNEL[1353.309872] add      /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.0/0003:1050:0407.0009/input/input4 (input)
KERNEL[1353.371106] bind     /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.0/0003:1050:0407.0009 (hid)
KERNEL[1353.371156] bind     /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.0 (usb)
KERNEL[1353.371200] add      /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.1 (usb)
KERNEL[1353.374674] add      /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.1/0003:1050:0407.000A (hid)

lsusb sees it fine

$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 1050:0407 Yubico.com Yubikey 4 OTP+U2F+CCID
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

gpg does not recognise the device for my user

$ gpg --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

gpg recognises the device for root

$ sudo gpg --card-status
[sudo] password:
Reader ...........: Yubico YubiKey OTP FIDO CCID 00 00

I also tried this pointer dorssel/usbipd-win#127 (comment) without success

It certainly seems like all this is close to working, but I can't tell where the answer is, only conclude that my user does not recognise the device while root does.

I haven't tried personally, as I've made it successfully and reproducibly work without usbipd-win and having to rebuild the kernel. Here's a guide I've composed on it from several other guides: https://gist.github.com/dinvlad/a62d44325fa2b989a046fe984a06e140

I have a very similar setup from https://blog.nimamoh.net/yubi-key-gpg-wsl2/ but it's janky and I'd rather get something closer to scdaemon working properly/natively instead of passing messages between WSL to Gpg4Win through socat glue.

Did you try adding yourself to the plugdev group? (or whichever group your udev rules are using for the yubikey) <- the root user isn't magic (most of the time) but it usually has more memberships than normal users, hence why it can see the device but you can't.

[matrixes]

Updated post

---

Did you try adding yourself to the plugdev group? (or whichever group your udev rules are using for the yubikey) <- the root user isn't magic (most of the time) but it usually has more memberships than normal users, hence why it can see the device but you can't.

As far as I can tell I have been a member of that group since default install. I haven't touched my memberships and this is what I'm a member of:

$ groups
m adm dialout cdrom floppy sudo audio dip video plugdev netdev

plugdev is the one that keep being used in pretty much all of the examples/instructions for how to set up udev for devices (Yubikeys included).
As a side note, I have an ATMega32u4 that I can interact with (e.g. flashing QMK firmware), and that's been working even without compiling a custom kernel. This Yubikey business is really throwing me for a loop.

[matrixes]

I recently reinstalled to Windows 11. Following these instructions https://docs.microsoft.com/en-us/windows/wsl/connect-usb (making doubly sure to update to the latest wsl-kernel) I still had the same initial issue; I could access the Yubikey as root, but not as non-root.

However, this workaround sudo service pcscd start - dorssel/usbipd-win#127 (comment), make the Yubikey available in usersworld for me.

I only wish this was a bit smoother, e.g. by being able to tell pcscd to restart when it sees the device using udev rules (for now), but I couldn't figure out how to make that work. In all other regards my Yubikey now works the way I want it to, even if it means having to manually restart pcscd.

[onyxcherry]

I recently reinstalled to Windows 11. Following these instructions https://docs.microsoft.com/en-us/windows/wsl/connect-usb (making doubly sure to update to the latest wsl-kernel) I still had the same initial issue; I could access the Yubikey as root, but not as non-root.

However, this workaround sudo service pcscd start - dorssel/usbipd-win#127 (comment), make the Yubikey available in usersworld for me.

I only wish this was a bit smoother, e.g. by being able to tell pcscd to restart when it sees the device using udev rules (for now), but I couldn't figure out how to make that work. In all other regards my Yubikey now works the way I want it to, even if it means having to manually restart pcscd.

Your gpg-related functionality works well, right?
How about FIDO2-related ones? (e.g. ykman list and ykman fido info, ran as the root of course)

[matrixes]

Your gpg-related functionality works well, right?

Yup. I use it mainly for this.

How about FIDO2-related ones? (e.g. ykman list and ykman fido info, ran as the root of course)

I haven't used these so I'm just entering them as you state them;

$ ykman list
YubiKey 5C Nano (5.1.2) [OTP+FIDO+CCID] Serial: [redacted]

$ ykman info
Device type: YubiKey 5C Nano
Serial number: [redacted]
Firmware version: 5.1.2
Form factor: Nano (USB-C)
Enabled USB interfaces: OTP, FIDO, CCID

Applications
FIDO2           Enabled
OTP             Enabled
FIDO U2F        Enabled
OATH            Enabled
YubiHSM Auth    Not available
OpenPGP         Enabled
PIV             Enabled

The command below made no difference when run as root.

$ ykman fido info
Error: No YubiKey found with the given interface(s)

[onyxcherry]

😮
My Yubikey Blue isn't detected even on restarting pcscd, sadly (contrary to the yours).
What's wrong...

[SheepReaper]

Blue is the FIDO one right? are we sure that one works yet? So far I've only seen confirmations for the 5 series nano and the regular one (keychain nfc)

[bacongobbler]

Tacking on my personal experience here as well.

Your gpg-related functionality works well, right?

Yes. After attaching the device and starting pcscd with sudo service pcscd start, I am able to use the YubiKey with gpg --card-status.

How about FIDO2-related ones? (e.g. ykman list and ykman fido info, ran as the root of course)

Similar story to @matrixes here. ykman list works, but not ykman fido info.

Powershell:

PS C:\WINDOWS\system32> usbipd wsl list
BUSID  DEVICE                                                        STATE
1-3    Goodix fingerprint                                            Not attached
1-4    MediaTek Bluetooth Adapter                                    Not attached
2-2    Microsoft Usbccid Smartcard Reader (WUDF), USB Input Device   Not attached
2-3    USB Input Device                                              Not attached
PS C:\WINDOWS\system32> usbipd wsl attach -b 2-2

gpg:

bacongobbler@broodlord ~ ><> lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 1050:0407 Yubico.com Yubikey 4 OTP+U2F+CCID
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
bacongobbler@broodlord ~ ><> sudo service pcscd restart
 * Restarting PCSC Lite resource manager pcscd                                                                   [ OK ]
bacongobbler@broodlord ~ ><> gpg --card-status
Reader ...........: Yubico YubiKey OTP FIDO CCID 00 00
Application ID ...: D2760001240103040006151497850000
Application type .: OpenPGP
Version ..........: 3.4
Manufacturer .....: Yubico
Serial number ....: 15149785
Name of cardholder: Matthew Fisher
Language prefs ...: en
Salutation .......:
URL of public key : https://github.com/bacongobbler.gpg
Login data .......: bacongobbler
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 221
KDF setting ......: off
Signature key ....: FEC0 BAEB F34B D22B DFB8  F385 887E D804 87CE 4E0F
      created ....: 2021-10-14 16:36:07
Encryption key....: AF60 23B1 29F9 8869 8640  FFAC 8B4D 4C49 9708 809C
      created ....: 2021-10-14 16:36:34
Authentication key: AAC1 542B 6F2D 1F81 16E5  C36B 9C67 2D4C 8C6C AE87
      created ....: 2021-10-14 16:36:56
General key info..: [none]

ykman:

bacongobbler@broodlord ~ ><> ykman info
Device type: YubiKey 5 NFC
Serial number: 15149785
Firmware version: 5.4.3
Form factor: Keychain (USB-A)
Enabled USB interfaces: OTP, FIDO, CCID
NFC transport is enabled.

Applications    USB     NFC
FIDO2           Enabled Enabled
OTP             Enabled Enabled
FIDO U2F        Enabled Enabled
OATH            Enabled Enabled
YubiHSM Auth    Enabled Enabled
OpenPGP         Enabled Enabled
PIV             Enabled Enabled
bacongobbler@broodlord ~ ><> ykman fido info
Error: No YubiKey found with the given interface(s)

As a result I am unable to access the FIDO2 resident key for SSH, so I have to resort to use the GPG key instead.

[1-bit-wonder]

I got this working and wrote a tutorial, for anyone interested.

[Neurrone]

@1-bit-wonder does this work for user presence detection as well as setting a pin? Have you noticed any issues with that approach?

I'm currently using windows-fido-bridge but it isn't fully reliable and doesn't work properly with ssh-agent. So I'm keen on finding better solutions.

[1-bit-wonder]

@Neurrone my pin was already set, so I can't say for sure, but I assume it should just work. it takes the pin fine on operations that require it. can confirm user presence detection works.

[SmartBoy84]

Is USB/IP going to be the only solution for connecting USB devices to WSL? As far as I know, this solution doesn't capture all cases, and sometimes traditional passthrough is essential.
I'm not sure if pentesting with wifi adapters (toggling monitor mode) works with this solution but a super niche case that I know for sure doesn't work is Checkra1n. I assume the reason this issue is still open is because others also want for this.

Why has Microsoft chosen this route, are there unresolvable issues with adding options for typical USB passthrough like other VM solutions?

[tyeth]

I got this working and wrote a tutorial, for anyone interested.

Thanks, you motivated me to try it, and now my ESP32's are flashing over WSL. 😱
A painless process to setup, although admin prompt in windows as I needed to force bind (using WireShark libUSBcap so --force), but 2-lines to mount/dismount makes it not overly hard and composite devices work fine.

[johnmccabe]

Has there been any sign from the team that they intend to support this natively, while usbipd works on Intel, it unfortunately isn't supported (not looks likely to be) on Arm (which makes working with the dev kit unpleasant).

[notaname2]

Is it possible to get native support for this usbipd unfortunately only works if you have adminstrator access. Which i don't on my work machine and that limits the ability to use Yubikeys from WSL linux distros. USB passthrough shouldn't need Local Admin.

[emaayan]

hi.. has anyone managed to get this working with usb wifi adapters?
i did the attach and when i do lsusb on wsl i get
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2357:011e TP-Link AC600 wireless Realtek RTL8811AU [Archer T2U Nano]
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

but when doing iwconfig i still can't see any wi-fi adapters

[samchouse]

WiFi is shared from Windows to WSL, no need to set it up on WSL.

[SmartBoy84]

Is native support coming?

[koffes]

Another ping and request for status on native USB support. Especially valuable for embedded devices, serial ports etc.. Many kudus to https://github.com/dorssel/usbipd-win/, but this really needs to be supported natively. Is it in any timeline?