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... https://github.com/ethanhs/WSL-Programs/issues/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 https://github.com/ethanhs/WSL-Programs/issues/29#issue-170066892 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.

[svrooij]

I'm looking for Yubikey support inside WSL. There was a UserVoice (no longer available), and this issue (closed) referring to this issue that is open since may 2016 and also referrers to this issue.

With the uservoice gone, and no real progress on this topic, how do we as users get the engineers to build something?

[svrooij]

My only concern is support for Yubikeys (or similar) for ssh authentication from a Windows machine. I though having this in WSL(2) would make it easy.

Plug-and-play support for Yubikeys for ssh auth on Windows is also fine with me. Currently you have to follow some 3 page manual and install several apps.

[darkRaspberry]

This is not as heated as VMMEN error. 😄 👍

[MrEmanuel]

My use case is to flash and debug my micro controller developer board. (i.e https://www.st.com/en/evaluation-tools/stm32f3discovery.html )

[dewstend]

My use case is ADB and bluetooth development. I like to tinker with my DualShock3 controller and pairing it to my Android. Sometimes I debug ethtool, so network interfaces would be nice too.

[dinvlad]

Definitely first-party YubiKey support from within WSL would be nice. We're using this with PIV and GPG functions. While there are workarounds for the latter, there're none at the moment for the former, afaik.

[svrooij]

@dinvlad at the moment I would settle for first-party Yubikey support on Windows SSH client. Instead of using a 4 page manual that doesn't always leads to the correct result.

[MrEmanuel]

For anyone following this issue and, as I am, waiting for the possibility to flash to a micro controller or similar via usb, the latest update (windows-10-insider-preview-build-20211) unfortunately doesn't seem to support it. Only USB hard drives seem to be supported, not flash drives.

See the "limitations" section at the bottom here for more information: https://docs.microsoft.com/en-us/windows/wsl/wsl2-mount-disk https://blogs.windows.com/windows-insider/2020/09/10/announcing-windows-10-insider-preview-build-20211/

I'm waiting patiently and looking forward to get flash drive support in WSL 2. :)

[tommai78101]

@MrEmanuel They have pulled the update.

[otakenz]

My use case is software defined radio and srsLTE software. Wish to use wsl2 as development platform for radio LTE.

[vikramkapoor]

My usecase is USB Webcam support in WSL2

[jano42]

Usecase : usb dongle (pcsc reader). Use to "sign" my applications

[doxxx]

Use-case: Connecting via USB to a Texas Instruments MSP432 development board in order to flash new firmware using OpenOCD. The dev board incorporates TI's XDS-110 JTAG debug probe. This works using the Windows version of OpenOCD, but using that from shell scripts running in WSL is a bit janky.

[tgarc]

Usecase: Connecting to USB-UART interface on various microprocessors and microcontrollers

[digitalentropy]

Use-Case: Literally trying to do any development work on a device that uses a USB-Serial interface, especially libusb devices.

It is mind boggling that more focus hasn't been put into developing this feature. Literally every other VM vendor has had this figured out for over a decade.

[gaia]

we have to maintain a dedicated ubuntu box solely because there is no USB pass-through in WSL.

[lucasfolino]

I think this is the feature that is most missed and has the most potential to allow most use cases to allow WSL to allow for a lot of new workflows. A true USB passthrough would allow for wireless controller for Kali Linux. Right now Kali Linux is hamstrung and not able to truly replace a laptop/virtual machine. It would be best to just have a separate box for this if you need any extra hardware for pen testing which usually you do. I also see this being important for SDR, Raspberry Pi development, Arduino development or other USB connected development like FPGA and other boards.

As for development purposes this would allow access to Android through Linux for build/push. And allow direct debug when network access is not available. There are other use cases as well, but these are the specific ones that are really holding me back from using WSL and Hyper-V as a whole. WSL is nice for some scripting and access to certain tools, but I still need another machine or virtual machine for other things I do. So I tend to just use the Linux box for all Linux scenarios instead of using WSL.

Don't get me wrong I love the idea of WSL and it would be nice to be able to have one single place to do my work. I actually prefer Windows for development I am a C# developer, but I also have interests in many things and spinning up Linux when I want to do some other work or testing is always a pain. Having access to Windows files is super nice and I love where WSL is going, but this is the one feature that is sorely missing and making WSL truly great.

[cheynewallace]

My company is 100% Linux & Mac based and i've been floating the idea of building some powerful PCs and moving our Linux workflow to WSL. I was able to build a pretty solid PoC so far (the GUI part is a little iffy, but acceptable), but this USB issue has stopped me in my tracks.

We do a fair bit of disk imaging work, we also distribute our software for the Raspberry Pi which we generally do in the form of a disk image. We snapshot SD cards mounted as USB volume pretty often. Currently, our custom tool chain leverages Linux dd to perform imaging operations. I assumed this would be fine, but apparently not as we cannot mount a USB disk.

Proposing to my team a migration to Windows development machines was hard enough already, but proposing we can simply use the same toolchain of bash scripts and standard linux tooling inside of WSL with more powerful hardware was a much easier pitch. "Its 100% linux, no emulation" I said, which raised some eyebrows of suspicion.

Splitting our tool chain half inside of WSL and half in native Windows is a deal breaker unfortunately, it means that whole argument of being able to do 100% of our work in Linux in Windows no longer stands true.
Im sure a lot of companies are in the same boat here when I say that lacking some core pieces of functionality like USB mounts unfortunately means WSL is a neat tool for Windows users for us but not a serious contender to switch our development environments over. I think what's been done so far is excellent work, the WSL team should be commended and I had already started planning our Ryzen 5000 PCs, but its not quite able to replace a Linux / Mac development workflow without some of these core features.

[tyeth]

@cheynewallace Have you got the latest WSL2 as it supports USB disk mounts now. https://docs.microsoft.com/en-us/windows/wsl/wsl2-mount-disk

Still not USB passthrough for everything yet like we all dream of, and yes the duel OS / nightmare dev build systems still exist but can be okay if you containerise everything except the firmware pushing (usb device issues). Still a lot of hair pulling though YMMV.

[lucasfolino]

If I am not mistaken the mounting would not allow for the workflow @cheynewallace is talking about. For dd to work you would need raw access the device and not mounting a partition. DD works on the block level of the drive. If any one has experience and knows that dd has worked in WSL for a mounted drive please correct me.

[gaia]

another reason to do n USB passthrough: it shouldn't take these many steps to use a yubikey for SSH auth https://blog.nimamoh.net/yubi-key-gpg-wsl2/

[tyeth]

@cheynewallace and @lucasfolino I just noticed that bare drive support is mentioned at https://github.com/microsoft/WSL/issues/689#issuecomment-719797262 , and once used bare disk access is enabled for dd.

List disks with: wmic diskdrive list brief then mount into wsl2 with wsl --mount \\.\PHYSICALDRIVE2 --bare for example.

https://docs.microsoft.com/en-us/windows/wsl/wsl2-mount-disk

Also the iScsi solution seems reliable and promising: https://github.com/jovton/USB-Storage-on-WSL2

[cheynewallace]

Very interesting, thank you for that @tyeth, that does sound like it may work, i'll try and test this soon.
I read here (https://devblogs.microsoft.com/commandline/access-linux-filesystems-in-windows-and-wsl-2/) that there is a limitation about mounting individual partitions but that shouldn't matter for us, we're imaging the full physical disk.

[dinvlad]

Could someone explain, in layman terms, what are the technical challenges in enabling a full USB pass-through in WSL2? My understanding, it's mainly on the Hyper-V side of things, whereas guest USB kernel driver can already be enabled/used in WSL2 if the host actually passed the device to it. Does anyone have any suggestions/ideas on how we could go about implementing it on the Hyper-V side?

Another potential workaround (which may or may not be that good performance/compatibility-wise) is to develop a general-purpose stand-alone "USB server" of sorts that would use a Hyper-V socket to communicate with a "USB client" inside the VM. I know this was proposed a while back in other issues, but all of those were closed and linked to the current issue, I think..

Someone also implemented a USBIP-based forwarding - never had a chance to try it, has anyone else here? https://github.com/rpasek/usbip-wsl2-instructions

[lucasfolino]

There are certain devices I do not think that USBIP would work well for. Mainly low latency devices like wireless network cards, DACs, or video processing. I could even argue USB disks. USBIP is more designed to have a remote device be able to be networked and not physically present. The overhead of the IP stack would just complicate things. Plus this should be a baseline feature for any form of virtualization similar to DVD/CD pass through/virtualization. USB is so prevalent that it shocks me that it isn't already available and really makes Hyper-V and in extension WSL not really good for a lot of work loads and inferior in a lot of ways to VirtualBox or VMWare. Especially in hardware arena where you need to interface directly to a device to flash, or have raw access. Hyper-V though does get a lot of things right when it comes to server virtualization. With that said WSL was designed for developers mostly and I think it has opened doors for workflows that haven't existed in the past. For me this is the one single thing that is holding me up and making me keep a physical Linux box around.

[dinvlad]

Yep, agreed. That's why a socket-based workaround might perform better (but still inconvenient, because of the extra need to configure the guest still). But it would still be best to just enable native pass-through. I just don't have enough context on why it cannot be simply enabled as a flag in Hyper-V, given that Hyper-V seems to support that in general (not necessarily with WSL2).

EDIT: Looks like I may be mistaken here, non-storage USB pass-through is not supported in general yet, as you noted: https://redmondmag.com/articles/2018/05/17/usb-passthrough-in-hyperv.aspx. This would explain things..

[dinvlad]

So, granted that a more general Hyper-V USB support seems to be a much bigger ask and not worth holding our hopes for, do you think it'd be worth exploring the socket idea?

[vikramkapoor]

IP over USB is worth exploring. I had tried an existing solution but it didn't work. I didn't have time to debug it. On Tuesday, December 1, 2020, 01:14:00 PM PST, Denis Loginov notifications@github.com wrote:

So, granted that a more general Hyper-V USB support seems to be a much bigger ask and not worth holding our hopes for, do you think it'd be worth exploring the socket idea?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[dinvlad]

@vikramkapoor I'm leaning more towards Hyper-V sockets, as those are in-memory and are supposed to have a (much?) higher performance. Existing APIs don't seem too complicated to set this up: https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/using-winusb-api-to-communicate-with-a-usb-device https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/make-integration-service

Starting in Windows 10 Anniversary Update, anyone can make applications that communicate between the Hyper-V host and its virtual machines using Hyper-V sockets -- a Windows Socket with a new address family and specialized endpoint for targeting virtual machines. All communication over Hyper-V sockets runs without using networking and all data stays on the same physical memory. Applications using Hyper-V sockets are similar to Hyper-V's integration services.

[therealkenc]

USB support seems to be a much bigger ask and not worth holding our hopes for

Never say never

[marecl]

Usecase: libusb WSL2 is a real help for Arduino/AVR in general. I'm working with V-USB and if I were using Windows for testing I would just abandon the project. Switching between vbox and windows is quite a hassle.

[murbanowicz]

Is there any chance it's going to be added to WSL? To me it is a thing which made me started thinking about moving to Mac...

usecase: mobile development

[dinvlad]

@murbanowicz for Android dev it's already possible with adb running on Windows host, I believe - please see https://github.com/microsoft/WSL/issues/2195#issuecomment-307282162

for iOS I don't think one can use anything but Mac, unfortunately.. that being said, there are some "Mac instances in the cloud" now, might be useful if you're into remote dev https://aws.amazon.com/blogs/aws/new-use-mac-instances-to-build-test-macos-ios-ipados-tvos-and-watchos-apps/

[digitalentropy]

Disclaimer for @dinvlad This is absolutely not meant target your most recent reply but rather just a venting in general about all of the [highly limited] workarounds that have been posted in the comments so far. It is meant to make clear to the development team that the current state of things is Not Okay.

I keep seeing people post workarounds, and I cannot help but be frustrated by the tone deaf nature of the some of the responses doing so.

There is this absolutely insidious pattern in software development or tech in general where someone says "I want to do X, and I'm having trouble making that work" and a bunch of folks suggest "You don't need X, try Y or Z".

I understand that the heart of it all everyone wants to be helpful, but the nature of this problem is very simple. There is no functional USB pass-through functionality in WSL2, and this materially and negatively impacts a WIDE variety of applications for power users and developers alike.

It is a critical feature for a lot of us that completely undermines the utility of WSL2 as a whole.

As a result, I am still finding myself making extensive use of commercial virtual machine platforms such as VMware.