usbipd-win
usbipd-win copied to clipboard
No longer able to access FTDI device in WSL2
I'm on Windows 11 and using WSL2 with Ubuntu-20.04. In July 2023 I followed the instructions at Connect USB devices usbipd to attach an FTDI to USB device. I did it successfully for several months. After several months of not attaching any USB devices to WSL2 I went to try it again and it's not working.
It seems that I can still successfully bind and attach my usb device to WSL2 (though I previously didn't need to use the bind command) and here's the result
C:\Windows\System32>usbipd list
Connected:
BUSID VID:PID DEVICE STATE
2-1 0403:6015 USB Serial Converter Not shared
2-5 048d:c102 USB Input Device Not shared
2-9 048d:c975 USB Input Device Not shared
2-10 8087:0033 Intel(R) Wireless Bluetooth(R) Not shared
4-1 046d:c52f USB Input Device Not shared
C:\Windows\System32>usbipd bind --busid 2-1
C:\Windows\System32>usbipd list
Connected:
BUSID VID:PID DEVICE STATE
2-1 0403:6015 USB Serial Converter Shared
2-5 048d:c102 USB Input Device Not shared
2-9 048d:c975 USB Input Device Not shared
2-10 8087:0033 Intel(R) Wireless Bluetooth(R) Not shared
4-1 046d:c52f USB Input Device Not shared
Persisted:
GUID DEVICE
79716af9-3cbb-4c92-a580-c1d5bc44050c USB Mass Storage Device
d5c67876-80cc-4f34-8f62-b43d66700e86 USB Serial Converter
C:\Windows\System32>usbipd attach --wsl --busid 2-1
usbipd: info: Using WSL distribution 'Ubuntu-20.04' to attach; the device will be available in all WSL 2 distributions.
usbipd: info: Using IP address xxx.xx.xxx.x to reach the host.
After doing that I should see the device listed as /dev/ttyUSB0
but this is what I see
$ ls -l /dev/ttyU*
ls: cannot access '/dev/ttyU*': No such file or directory
I did uninstall the version of usbipd that I was using and installed the latest, but no dice. I've looked all over but none of the suggestions I've found online have yielded any results. I didn't change anything so I'm not sure why it stopped working all of a sudden.
Can someone help me troubleshoot this?
Does lsusb
list the device as attached in WSL? If so, then you are probably missing the right driver for this device in the kernel.
Here's the output of lsusb
before and after I attach the device
~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
:~$
So it looks like it is listed. I'm curious, how could I be missing the right driver for this device in the kernel when it was working previously, and with no changes to my WSL2 instance it just stops working?
Here's my WSL2 info
C:\Windows\System32>wsl --version
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3447
Also, how would I install the driver for this device if it is missing all of a sudden?
Hmmm. This is a fairly standard FTDI device. And a driver is included in the stock WSL kernel.
You said it worked before? How long before? Because:
Kernel version: 5.15.146.1-2
is relatively new (see https://github.com/microsoft/WSL2-Linux-Kernel/releases/tag/linux-msft-wsl-5.15.146.1).
Maybe it is udev
, maybe you need to enable systemd
. I don't know, I am not a WSL expert. All I can tell is that the attach worked properly; the problem is with WSL.
I know I was using it last year after July at least. It's been a few months since I have connected this device. But the only things I've been doing in my WSL2 instance is compiling my c++ code, sometimes switching to WSL version 1 and then back to version 2, and the occasional sudo apt update
depending on what I'm working on. I wonder why my kernel version is so new if I installed WSL last year.
Okay so I found these instuctions Run FTDI USB devices on Windows 10/11 WSL2 which I found here FTDI device not working WSL with usbipd-win. This issue also pointed to that same blog so I'm gonna post it here in case anyone else finds it helpful WSL/issues/11346
In the instructions it has you install pahole and that didn't work for me initially, so I installed it following the instructions in the repo python-pahole-utility
At the end of all of that I finally see
$ ls -l /dev/ttyU*
crw------- 1 root root 188, 0 May 11 15:32 /dev/ttyUSB0
Ah, I hadn't realized that Microsoft changed the way they build the kernel. Previously it was monolithic (all drivers built-in), but apparently they switched to modules:
user@wsl:~$ zgrep FTDI /proc/config.gz
CONFIG_USB_SERIAL_FTDI_SIO=m
# CONFIG_USB_FTDI_ELAN is not set
user@wsl:~$ sudo modprobe ftdi_sio
user@wsl:~$ lsmod
Module Size Used by
ftdi_sio 49152 0
usbserial 36864 1 ftdi_sio
user@wsl:~$
These are the ones that are now modules:
user@wsl:~$ zgrep =m /proc/config.gz
CONFIG_NET_IPIP=m
CONFIG_INET_TUNNEL=m
CONFIG_IPV6_SIT=m
CONFIG_NETFILTER_XT_TARGET_CT=m
CONFIG_NETFILTER_XT_MATCH_BPF=m
CONFIG_NETFILTER_XT_MATCH_U32=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BONDING=m
CONFIG_DUMMY=m
CONFIG_NET_VRF=m
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_CH341=m
CONFIG_USB_SERIAL_CP210X=m
CONFIG_USB_SERIAL_FTDI_SIO=m
user@wsl:~$
Change happened in Januari: https://github.com/microsoft/WSL2-Linux-Kernel/commit/afb2c95c4a0524e8a279a246c1ba8cf1dbb7a6a0
Oh, so those things that we previously built in, by default with the kernel update are now modules you have to install separately? Did I install all of those modules you listed, or just the SERIAL_FTDI module? I don't know too much about the kernel I built, just followed the instructions.
If you use systemd
(I recommend that you enable it), the module will load automatically (at least, it does on my machine). If not, you will have to load the module with sudo modprobe ftdi_sio
.
@dorssel solution works for me too.
Actually, it is not necessary to rebuild the kernel like @crose72 did in his previous message. It is sufficient to enable systemd on WSL.
@mrv96 Sweet! I'm glad you confirmed that, rebuilding the kernel, though it was pretty straightforward from the instructions, is not ideal. Simpler is better.
Since there seem to be two solutions here I guess I'll close the issue :) Thanks again @dorssel!
Add modprobe ftdi_sio
to /etc/rc.local and there is no need to install systemd. Why they didn't add other USB dongles like Prolific is beyond me... They use modules, but still limit the supported hardware out of the box. The only penalty of a prolific module would be the disk overhead (which could be in an optional package to even avoid that).
Also issue triggers with a WSL2 update (which is incidentally related to a Window 11 upgrade). For instance running wsl.exe --update
from a command prompt.