Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No longer able to access FTDI device in WSL2 #948

Closed
crose72 opened this issue May 11, 2024 · 12 comments
Closed

No longer able to access FTDI device in WSL2 #948

crose72 opened this issue May 11, 2024 · 12 comments

Comments

@crose72
Copy link

crose72 commented May 11, 2024

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?

@dorssel
Copy link
Owner

dorssel commented May 11, 2024

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.

@crose72
Copy link
Author

crose72 commented May 11, 2024

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?

@dorssel
Copy link
Owner

dorssel commented May 11, 2024

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.

@crose72
Copy link
Author

crose72 commented May 11, 2024

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.

@crose72
Copy link
Author

crose72 commented May 11, 2024

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

@dorssel
Copy link
Owner

dorssel commented May 11, 2024

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:~$

@dorssel
Copy link
Owner

dorssel commented May 11, 2024

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:~$

@dorssel
Copy link
Owner

dorssel commented May 12, 2024

Change happened in Januari: microsoft/WSL2-Linux-Kernel@afb2c95

@crose72
Copy link
Author

crose72 commented May 12, 2024

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.

@dorssel
Copy link
Owner

dorssel commented May 12, 2024

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.

@mrv96
Copy link

mrv96 commented May 29, 2024

@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.

@crose72
Copy link
Author

crose72 commented May 29, 2024

@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!

@crose72 crose72 closed this as completed May 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants