USB device support, libusb (ADB support, etc)
timcanham opened this issue · comments
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 runstrace -o strace.txt -ff <cmd>, and post the strace.txt output here)
n/a
See our contributing instructions for assistance.
Perhaps related to #825.
@timcanham - I'm not sure but... ethanhs/WSL-Programs#29 and the first raw of list in https://github.com/ethanhs/WSL-Programs .
The image they showed seemed to indicate it work in cmd.exe but not bash.
@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.
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.
@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.
thanks @ReVanTis , now i can build rom for my xperia.... my adb now is showing my device...
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:
- there are same version of adb in bash and cmd.
- start adb-server in cmd first, and make sure adb-server running in windows end.
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).
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.
@ReVanTis May I know how do you get to make both ADB in bash and cmd the same version? Thank you for your time.
@kengkeelim Download here: https://developer.android.com/studio/releases/platform-tools
Download both Linux and Windows version and use them together.
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.
anyhow WSL-Programs will die because WSL 2 coming.
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.
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?
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.
This is not as heated as VMMEN error. 😄 👍
My use case is to flash and debug my micro controller developer board. (i.e https://www.st.com/en/evaluation-tools/stm32f3discovery.html )
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.
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.
@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.
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. :)
@MrEmanuel They have pulled the update.
My use case is software defined radio and srsLTE software. Wish to use wsl2 as development platform for radio LTE.
My usecase is USB Webcam support in WSL2
Usecase : usb dongle (pcsc reader). Use to "sign" my applications
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.
Usecase: Connecting to USB-UART interface on various microprocessors and microcontrollers
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.
we have to maintain a dedicated ubuntu box solely because there is no USB pass-through in WSL.
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.
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.
@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.
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.
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/
@cheynewallace and @lucasfolino I just noticed that bare drive support is mentioned at #689 (comment) , 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
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.
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
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.
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..
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 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.
USB support seems to be a much bigger ask and not worth holding our hopes for
Never say never
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.
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
@murbanowicz for Android dev it's already possible with adb running on Windows host, I believe - please see #2195 (comment)
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/
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.
I completely agree with @digitalentropy. This is a feature that for me makes or breaks WSL. Right now WSL is more a fun little cool I can do that, or the occasional drop down to WSL to run a command like rsync or a quick script. I still need to have a full VM for things like Kali for wireless pen testing, or another distro for SDR work. I also use Linux for Arduino or other instance where I need to flash firmware to something and to be honest Linux has better tools for that job. Not as much for the Arduino, but since I need to flash other stuff my toolchain is in Linux since I need it any way.
I also agree @digitalentropy - unfortunately in this case though, this is not entirely WSL2's fault, since native USB pass-through is just not supported by Hyper-V, if it wasn't clear :)
I think to "properly" solve this problem we need to reach Hyper-V team somehow, and ask about their roadmap for USB pass-through (if any). Without that, I'd be glad to try my hand at the Hyper-V sockets proxy solution I suggested above, although being a workaround, this may or may not solve the problem for most. I'm not sure what else WSL2 team has up their sleeve however..
+1 for me as well. I have a use case where I need to connect some USB3 cameras to a linux WSL and then everything else is great. I also need to connect some UBlox GPS USB to a Linux WSL. USB passthrough matters a lot.
usercase: mobile development
Trying to mess around with my iPhone without MacOS because I don't want to pay for it. I assumed that I would be able to use "libimobiledevice" and "ifuse" to do this with Linux to avoid building an physical version of Linux. I am just posting because I quite like both Windows and Linux, and would like to be able to "shove" both onto one machine with full functionality. I will return if I learn anything useful.
Thank you everybody who has contributed to this thread and the closed threads! Without you all I'd be much more lost than I am already.
I'm using Buildroot to create an OS for an IoT style audio device. Great having WSL2 on my WinPC for doing that. Not so great that I can't dd a USB stick. Seems this would be a wonderful feature.
This is needed for scenarios like docker - i have number of applications that require USB devices like USB serial zwave adapters, google coral for tensor flow applications, etc.
Hi, So I just reinstalled windows and my work usually uses OpenCV, webcam, and mxnet, In the previous versions I couldn't get them to work with wsl, I was wondering if anything has changed in these few months?
+1, only reason i need a actual linux machine around me is due WSL not supporting this.
Likewise +1
I am unconvinced anyone from MS looks at the WSL/WSL2 issues any more - take a look at the mess of a github issue about DNS issues where people keep posting the same workarounds to an underlying set of bugs in the networking stack of windows / hyper-v / WSL2 - any github issue that turns into a chat forum or support thread is DOA in terms of being useful. Including this one :-(
I have stopped bothering to file as MS can't be bothered to actually manage their issues lists 1.1k un-addressed issues means this git repo is not being managed in any meaningful way and causing terrible signal to noise issues. Shame as WSL is freaking awesome. @satyanadella
the one bright spot i have had with MS and github is the filing of document issues / clarifications - they get addressed quickly. Funny document writers are doing better job with github than engineers :-)
I am unconvinced anyone from MS looks at the WSL/WSL2 issues any more - take a look at the mess of a github issue about DNS issues where people keep posting the same workarounds to an underlying set of bugs in the networking stack of windows / hyper-v / WSL2 - any github issue that turns into a chat forum or support thread is DOA in terms of being useful. Including this one :-(
I have stopped bothering to file as MS can't be bothered to actually manage their issues lists 1.1k un-addressed issues means this git repo is not being managed in any meaningful way and causing terrible signal to noise issues. Shame as WSL is freaking awesome. @satyanadella
the one bright spot i have had with MS and github is the filing of document issues / clarifications - they get addressed quickly. Funny document writers are doing better job with github than engineers :-)
I sadly found twitter to be the best form of support with a lot of companies including Microsoft (Shout out @AzureSupport team 🥳 ). They almost always want to take it into DirectMessages (to protect you / hide their shame) and more often than not it's a quick escalation tool, bypassing things like paid support quotas (they can grant you free support incidents), etc.
I found it to be prompt and thorough.
When I last looked for news in 2020 some key WSL2 people were at least present and shouting about new release features etc.
I am unconvinced anyone from MS looks at the WSL/WSL2 issues any more - take a look at the mess of a github issue about DNS issues where people keep posting the same workarounds to an underlying set of bugs in the networking stack of windows / hyper-v / WSL2 - any github issue that turns into a chat forum or support thread is DOA in terms of being useful. Including this one :-(
I have stopped bothering to file as MS can't be bothered to actually manage their issues lists 1.1k un-addressed issues means this git repo is not being managed in any meaningful way and causing terrible signal to noise issues. Shame as WSL is freaking awesome. @satyanadella
the one bright spot i have had with MS and github is the filing of document issues / clarifications - they get addressed quickly. Funny document writers are doing better job with github than engineers :-)
If MS abandons WSL, I will have to abandon Windows entirely.
I think the issue is that the development of WSL is tied directly to Windows development and updates. It seems to only get updates when Windows is updated. So it moves slowly. I don't think it is abandoned because they where pushing people to it pretty hard. I think the issue how coupled it is to Windows so it may be that to make some of the bigger changes require changes to be made in Windows. I think the USB change is probably one of those changes. Now if we get a few release cycles with no or very little movement in WSL I would agree that Microsoft doesn't care.
Yes, I think to keep it focused, we should ask what are the plans to enable USB pass-through in Hyper-V, and if there's a better avenue for us as users to communicate this request?
Hello,
As everyone mentioned before, it will be nice to know if we have any timeline from the Hyper-V team for usb passthrough.
This is a much needed feature in WSL.
Thanks
This issue is likely going unnoticed. This has been sought after since wsl's initial release yet Microsoft has only made vague attempts to address it, why?
I'd imagine it's hard to communicate such requirements between different teams, which is not uncommon in organizations both big and small. We should probably try to find how to reach out to Hyper-V team more directly.
Why can't WSL2 just provice some CLI or GUI tools like VMware Workstation's USB selection tool to let us select whether an USB device should connect to WSL or Windows?
However, the ideal situation is WSL 2 can access USB devices shared with Windows.
I also agree @digitalentropy - unfortunately in this case though, this is not entirely WSL2's fault, since native USB pass-through is just not supported by Hyper-V, if it wasn't clear :)
I think to "properly" solve this problem we need to reach Hyper-V team somehow, and ask about their roadmap for USB pass-through (if any). Without that, I'd be glad to try my hand at the Hyper-V sockets proxy solution I suggested above, although being a workaround, this may or may not solve the problem for most. I'm not sure what else WSL2 team has up their sleeve however..
Very good summary. Just wondering why Hyper-V is lacking USB support for so long.
I do not use Hyper-V or WSL simply because it does not support USB.
Ensure to have the same ADB version in windows and wsl2.
On Windows:
adb tcpip 5555Then on WSL 2:
adb connect [ip device]:5555If it's the first time, it's going to ask you for permission in your phone, make sure to check the box to always grant permission. Then restart adb and connect again:
adb kill-server
adb connect [ip device]:5555
Using adb in WSL2 is simplest and works well if you just (only) install adb in Windows and just call the adb.exe binary from within WSL2.
- Download from here https://dl.google.com/android/repository/platform-tools-latest-windows.zip
- Extract the contents of this ZIP file into C:\adb (or any other folder)
- Add the folder C:\adb\platform-tools to the Path environment variable in Windows (if you need help with this, see https://www.xda-developers.com/adb-fastboot-any-directory-windows-linux/ and follow the instructions for Windows). You may need to restart WSL2 after this to make the new Path apply within the WSL2 environment (test by running
adb.exein WSL2). - Add a symlink to adb.exe by executing:
ln -s $(which adb.exe) $(dirname $(which adb.exe))/adb
The symlink added in step 4 means you don't have to type adb.exe, but can just type adb in commands, as you would expect from a native install.
This is pretty clear that we all want an 'USB switch' feature just like VMWare provides.
This is pretty clear that we all want an 'USB switch' feature just like VMWare provides.
The only problem seems to be finding a way to contact Microsoft/Hyper-V since they are clearly not taking any notice of this thread (or at least haven't addressed it)
There is no point promoting this thread anymore.
What about this option? https://www.tenforums.com/virtualization/174394-how-add-webcam-windows-10-vm-hyper-v.html
@cnSchwarzer Do you know how vmware does that? Or at least a general overview or docs of that technology.
@Toumash @Biswa96 As the article says, it's using RemoteFX USB Device Redirection, which is a tech available only in Windows host and guest environments..
Thanks for the info - but also remember that your HYPER-V VM must be Windows PRO or above because RDP server won't run on Windows HOME. (This is the VM -- and also the HOST needs to be WINDOWS 10 pro or above to enable HYPER-V for VM creation).
Can you guys give this a try https://www.virtualhere.com/comment/9758#comment-9758 and see if it works ok regarding passing through
@virtualhere it's not a free/open-source solution and relies on network stack communication, with all of the disadvantages as already discussed above. I looked at that thread a while back, but decided not to try it because of these reasons. I'm sure it would work ok for non-latency-sensitive applications, but I don't think this would be ideal in all cases, unfortunately (thanks for making it though!). Plus, we're mostly looking for a native solution from Microsoft here! 😉
Can you guys give this a try https://www.virtualhere.com/comment/9758#comment-9758 and see if it works ok regarding passing through
@virtualhere Even USB/IP doesn't seem to work for me.
I've compiled and loaded the latest WSL2 kernel which reportedly has USB/IP enabled but I can't seem to connect any device - it always returns "failed". VirtualHere and the client connect successfully as I can do "-t list" to see all the connected devices. Neither side is running the application as a daemon/service.
I have been able to connect my Bluetooth dongle but nothing else seems to work (wifi adapters, serial adapters, iPhone, etc)
I have two use cases related to this:
- In work land i would like to be able to use my yubikey to auth to google for command line authorizations
- On personal i would like to be able to write to arduino or ESP chips from linux.
+1 would love USB support
On the release notes for kernel 5.10.60.1, it had this, Enable USB kernel configuration options for interacting with an Arduino over USB. Does anyone know what this does or changes?
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!
Thank you for bringing this to our attention for it may fulfill some use cases for USB devices on WSL. This is still a work around and not true USB passthrough. It sounds like it is more of a USB IP connection. For some use cases this would work great like programming a Pi/Arduino or firmware flashing where latency may not be as big of an issue. My use case is raw access to a device I use wireless device like any Alfa cards for use with Kali Linux for some network security tests.
I think this is pretty cool and will try for my Alfa cards when I get a chance, but it still seems that there may be some IP overheard or issues with USB over IP. I feel that this functionality should be part of Hyper-V/WSL and not rely on third party app. This feature is also why I have stayed away from Hyper-V because I do testing that requires dongles, or other USB attachments for authentication or access to a device.
Quick questions does this work in Windows 10 or only Windows 11. I wasn't sure if WSL on Windows 11 is different or has something Windows 10 doesn't which would cause this not to work.
Thanks @craigloewen-msft just filed my first issue against the project for service crash :-)
I plan to try a radio usb device and zwave dongle to see if this works once the service crash is solved.
Also how should we install winget on server - just install the winget package manually? (there is no store)
Quick questions does this work in Windows 10 or only Windows 11. I wasn't sure if WSL on Windows 11 is different or has something Windows 10 doesn't which would cause this not to work.
You'll need to compile the kernel yourself for Win10: https://github.com/dorssel/usbipd-win/wiki/WSL-support
Or maybe you can use a prebuilt https://github.com/nathanchance/WSL2-Linux-Kernel#readme in the future when it picks up those config changes.
You'll need to compile the kernel yourself for Win10: https://github.com/dorssel/usbipd-win/wiki/WSL-support
Actually it seems that the required WSL kernel update (5.10.60.1) is now offered at least for Windows 10 21H1 — I got it automatically installed on 2021-11-03, and USB/IP works for me (with some rough edges that don't seem to be related to Windows 10/11 differences — e.g., at the moment usbipd wsl attach works only when specifying a Debian/Ubuntu-based WSL instance; however, because all WSL instances actually run as containers within the same Linux VM, you can attach the device to a supported instance, but actually see the device in all other WSL instances running at the same time).
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.
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).
Anything new here?
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.
@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?)
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 #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 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
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-winin 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-winand 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.
I haven't tried personally, as I've made it successfully and reproducibly work without
usbipd-winand 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-winin 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) :(
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-winin 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-WSL2Kernel 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 hubgpg 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 devicegpg recognises the device for root
$ sudo gpg --card-status [sudo] password: Reader ...........: Yubico YubiKey OTP FIDO CCID 00 00I 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-winand having to rebuild the kernel. Here's a guide I've composed on it from several other guides: https://gist.github.com/dinvlad/a62d44325fa2b989a046fe984a06e140I 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.