microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.32k stars 814 forks source link

WSL2: Ubuntu 18.04 Serial devices are no longer mounted properly #4322

Open david-dumke opened 5 years ago

david-dumke commented 5 years ago

COM3-pic

Matheus-Garbelini commented 3 years ago

Indeed, Serial Port on WSL2 is a dream of every firmware engineer. Hope Microsoft can figure out how to add support for that soon.

vladkosarev commented 3 years ago

Still using wsl1 because of this and faster host-shared file system.

abobija commented 3 years ago

For those who wait WSL2 USB support for flashing ESP-IDF applications, I've wrote this Shell script with the help of which you can flash project with command idfx flash COM3 from WSL2. Or for monitoring: idfx monitor COM3.

And here is full tutorial how to install ESP-IDF on WSL2 (Ubuntu 20.04 LTS).

Cheers.

fungiboletus commented 3 years ago

In addition to the flashing workarounds, I found a way to make a TCP tunnel of the serial-port from Windows to WSL2 which can be useful if you want to read/write on the serial port.

You can download Null-modem emulator and execute the com2tcp-rfc2217.bat in PowerShell on the right serial port and an available TCP port you like. That will make a TCP server connected to the serial port.

.\com2tcp-rfc2217.bat COM3 5421

Then in Linux you can install socat and use it to connect to the TCP server and redirect the data to a virtual PTY. I didn't manage to connect to localhost from WSL2 to a Windows TCP Server but the IP on the local network works for me. You can find it using ipconfig and replace 192.168.1.10 in the following command.

socat -d -d tcp-connect:192.168.1.10:5421 pty,raw,echo=0

socat will print something like PTY is /dev/pts/3 and then you can use /dev/pts/3 as your virtual serial port.

edit: This may have a slightly different behaviour compared to a real serial port.

dsonyy commented 3 years ago

@fungiboletus I have tested your workaround, and it seems like the communication is estabilished. However, I have a problem with baudrate setting. After running com2tcp-rfc2217.bat, it by default prints ... baud=19200 .... I would like change it but I haven't found any working solution yet.

syamsidhardh commented 3 years ago

I'm eagerly waiting for a proper fix for this issue. I hope MS will fix this soon.

ocalvo commented 3 years ago

Frustrated that I cannot do development of the SMS integration for homeassistant with WSL 2.

daviddecobee commented 3 years ago

Disappointed after scanning through here that I had to downgrade to WSL1, currently using Ubuntu 20.04.

dandymon commented 3 years ago

BUMP! For all the reasons other people have mentioned on this thread, with a specific echo of what @daviddecobee said!!

adokitkat commented 3 years ago

Please Microsoft make this a high priority...

bnystrom commented 3 years ago

Stuck in WSL 1 land also since I rely on WSL for doing microcontroller development and rely on USB communication with physical hardware.

kingsumos commented 3 years ago

This issue happens in other distros as well (e.g openSUSE 15.1/15.2).

grizmin commented 3 years ago

bump

jjclose commented 3 years ago

I'm in the same boat as most other people here. After discovering this issue exists, I'm currently deciding whether to downgrade to WSL 1 or to switch to my Mac for development.

rickiewars commented 3 years ago

I'm in the same boat as most other people here. After discovering this issue exists, I'm currently deciding whether to downgrade to WSL 1 or to switch to my Mac for development.

I've already switched to linux for all of my workflow due to this issue. I only rely on Windows for some games at the moment and honestly, I don't even miss my Windows installation. I know that for most users this won't be possible but for those who can, give it a chance!

Edit: Oh and Microsoft, fix this issue!

mkanet commented 3 years ago

Is there any way to tell if there is any active development for implementing this capability? Im currently using Oracle Virtualbox Linux VMs with USB filters for serial devices on Windows 10.

kattaliraees commented 3 years ago

This is a real bummer. Especially for hardware/firmware people. I am wondering if any work is happening for this issue. Looks like almost 2 years since this issue opened

wgaylord commented 3 years ago

So wait they can add GPU pass thru easily but can't add the far simpler USB pass thru? Referencing https://docs.microsoft.com/en-us/windows/wsl/wsl2-faq#can-i-access-the-gpu-in-wsl-2-are-there-plans-to-increase-hardware-support

paradajz commented 3 years ago

I had to edit the firmware flashing instructions under WSL for my project to explicitly mention that it works only on WSL1 since WSL2 can't see USB COM port devices. Having used WSL1 in the past I just assumed that, of course, WSL2 must also support this. Just learned recently about this. And yes it's quite unbelievable that GPU passthrough works but simple serial ports don't.

jjclose commented 3 years ago

I commented on this previously so I thought I would follow up in order to provide feedback to Microsoft WSL team. Since I badly need USB/COM ports in the Linux device setup, I was debating whether to revert back to WSL1 or use something else. In the end I decided to move to an Ubuntu box and have been happy ever since, and frustrated that I spent longer than I should have waiting on WSL. Sad to not have the parts of Windows that I was using, but those all have workarounds and the COM port issue does not.

mkanet commented 3 years ago

Is there a way to follow how far the WSL team has gotten in implementing USB/COM ports for WSL2 since July 2019?

rickiewars commented 3 years ago

Is there a way to follow how far the WSL team has gotten in implementing USB/COM ports for WSL2 since July 2019?

I haven't seen anything mentioned about this issue in their roadmaps so I'm assuming that no one inside the Microsoft team has been working on this. Still I can't say anything for certain.

@jjclose, Always nice to see that more people are fully switching to Linux and rely less on Windows :)

rajithavk commented 3 years ago

I'm surprised why they are not implementing this or showing any interest at all, basically that's the most important feature I'd need as an embedded engineer to use WSL.

xornet-sl commented 3 years ago

Bump!!!

bojanpotocnik commented 3 years ago

I agree that this feature is important, but there is no need to just "bump" this topic every 4 days and give hundreds of subscribed people fake hope with email notification. Considering that this is opened for almost 2 years, once per month is probably enough.

You can try writing an email to WSL Team as mentioned under Additional information - maybe this will get enough attention to at least provide official response to this issue and plan on fixing it.

jerrylogansquare commented 3 years ago

please, pretty please!

SunJun8 commented 3 years ago

WSL's IO performance is horribly low.If WSL2 does not support serial, it can only switch to linux completely

slorquet commented 3 years ago

I wonder if a tcp/serial bridge running on the host would help.

florianhumblot commented 3 years ago

@slorquet that does work, I'm currently using: https://github.com/abobija/idfx which is basically a TCP bridge between the host machine and WSL allowing for serial passthrough. Though this example is specific for esp-idf and esp tools

HStry commented 3 years ago

@bojanpotocnik Seeing as this is a fairly basic request, and it's already almost 2 years open without any official response by Microsoft, I'd say it's more than valid for people to be extremely frustrated about this. Sure, there are workarounds for some use cases, but not for every case. And if you're working with embedded systems or COM port connected sensors, it's a definite show-stopper.

Worse still, @microsoft doesn't recognize this issue here, but they do (through @msftbot[bot] auto-) close other issues as duplicates: https://github.com/microsoft/WSL/issues/6206#issuecomment-725040972_

jviskari commented 3 years ago

Is there any plans to make this work?

SunJun8 commented 3 years ago

Maybe Microsoft hasn’t figured it out yet

tzuriely commented 3 years ago

????????

JosuGZ commented 3 years ago

This is how I feel about it:

https://www.youtube.com/watch?v=BuLyxcyhbLQ

Damnit! Its sooo close!

BTW some talk about downgrading to wsl 1, is it possible? I've tried naively and now I get Error response from daemon: open \\.\pipe\docker_engine_linux: The system cannot find the file specified.

pmckeon commented 3 years ago

This is a problematic issue for those of us doing embedded development on platforms like Arduino / Espressif as you can not program a device over USB serial port.

MarkerViktor commented 3 years ago

Bump!

CrossMyHeart commented 3 years ago

Actually it's very important and necessary for embedded software debug. This issue is fatal to WSL2!!!!

jjclose commented 3 years ago

People, this has been going on for, literally, years. I strongly recommend that you make a decision and move on. I posted here and then quickly came to the realization that MS is not going to fix this, at least not on any reasonable timeline. They are clearly aware of this issue, and are ignoring it, so it is pointless to keep posting about it. I decided to ditch Windows and installed Linux, since the pain of what I am missing in Windows is not as bad as the pain of what I needed in Linux when working from Windows. There are only two reasons that I can think of that explain Microsoft's silence on this: either they really don't care about it and are abandoning the project, or they are not fixing this because they're working on something bigger regarding Linux.

d-c-d commented 3 years ago

Another alternative solution when a Linux system is not available is to use Cygwin, that's what I've done. Been using it from pre wsl days - just another tool

Trance-Paradox commented 3 years ago

Really I don't know why this fix is taking so long. Also am not aware of any conspiracy theories but M$ can bring GPU accelerated GUI and application support in WSLg but can just share a COM port in wsl2??? Its now even a new feature it was working in WSL1 is what I am aware off but even after so much time has passed no response from M$ devs. I don't know if M$ developer think this feature is not worthy or just want embedded system developers either to buzz of to native Linux or use the oversized MS built tools??? This guy from tab vs space i.e @craigloewen-msft if I am not wrong gives update over improvements in WSL. Even in rapid fire questions the serial port issue doesn't come up, o don't know why!

nbdd0121 commented 3 years ago

Really I don't know why this fix is taking so long.

This is far from trivial to implement. They'll likely need to implement a kernel module to support this. You can't even easily access a serial port on another Linux device as if it's a local serial port, needless to say about a serial port on Windows host.

Support it in WSL1 is much easier because it's only userspace APIs to replicate, no kernel module is needed.

Sending angry comments or meaningless bumps will not help the scenario and will only annoy readers. Many people subscribe to the issue for updates not complaints.

jjclose commented 3 years ago

Really I don't know why this fix is taking so long.

This is far from trivial to implement. They'll likely need to implement a kernel module to support this. You can't even easily access a serial port on another Linux device as if it's a local serial port, needless to say about a serial port on Windows host.

Support it in WSL1 is much easier because it's only userspace APIs to replicate, no kernel module is needed.

Sending angry comments or meaningless bumps will not help the scenario and will only annoy readers….

This is a silly response. People have been making this request for 2-3 years and getting absolutely zero response from Microsoft. It is very necessary and core functionality. Asking for a basic feature that still hasn’t been delivered annoys other readers? Probably not as annoyed as we are at lacking this feature. In addition, WSL2 already embeds an actual Linux kernel as opposed to a translation layer. There is obviously a plethora of other serial port driver code available for Linux, so it’s hard to imagine that this would be such a daunting task for MS as you describe.

rubberduck203 commented 3 years ago

The difficulty is likely due to WSL2 sitting on top of virtualization, unlike WSL1.

nbdd0121 commented 3 years ago

This is a silly response. People have been making this request for 2-3 years and getting absolutely zero response from Microsoft. It is very necessary and core functionality. Asking for a basic feature that still hasn’t been delivered annoys other readers? Probably not as annoyed as we are at lacking this feature. In addition, WSL2 already embeds an actual Linux kernel as opposed to a translation layer. There is obviously a plethora of other serial port driver code available for Linux, so it’s hard to imagine that this would be such a daunting task for MS as you describe.

I said angry comments or meaningless bumps annoy readers. Question marks and bumps serve absolutely no purpose in helping the scenario. If I work for WSL2 I'll completely disregard these comments.

Don't get me wrong, I absolutely want this feature, as many people do. I want it so bad that I even tried to implement this feature myself, and only then I learned that this task is more complicated than I expected. Kernel abstractions provided are very low-level for real devices and not for a virtual one like what is needed for this feature. The closest I can get is to go via pty but you cannot set baud rate via pty. And they'll also need to dynamically create and destroy these devices when COM ports are connected and disconnected from the host.

It is certainly doable given enough manpower, but it is far from trivial. Without infinite resource to implement all feature requests, I can understand why they prioritize features like WSLg which is wanted by more users.

HStry commented 3 years ago

Don't get me wrong, I absolutely want this feature, as many people do. I want it so bad that I even tried to implement this feature myself, and only then I learned that this task is more complicated than I expected. Kernel abstractions provided are very low-level for real devices and not for a virtual one like what is needed for this feature. The closest I can get is to go via pty but you cannot set baud rate via pty. And they'll also need to dynamically create and destroy these devices when COM ports are connected and disconnected from the host.

I've not had the time to look into this much yet, but I've been thinking of trying to make a com-over-ip kind of thing, where a driver on Windows would just transparently forward all information to and from a com port to the local network of WSL, where that has a driver that does the inverse. I've only looked for a few minutes into it, but I think I saw a serial-over-ip thing somewhere. But I'm currently in a bit of a home reconstruction/renovation, so...

siebert commented 3 years ago

I found this workaround, which seems to be promising (but I have not tried it yet): https://matevarga.github.io/esp32/m5stack/esp-idf/wsl2/2020/05/31/flashing-esp32-under-wsl2.html

void-spark commented 3 years ago

Wonder if @craigloewen-msft could let us know if this is even remotely on their radar :)

Trance-Paradox commented 3 years ago

Wonder if @craigloewen-msft could let us know if this is even remotely on their radar :)

Upvote this reply And It this only a problem for 18.04 like the heading says. I think this is a problem for all the distros

HStry commented 3 years ago

It this only a problem for 18.04 like the heading says. I think this is a problem for all the distros

Good point, didn't even see that. I'm using Debian, and same issue there. @strike5150 could you make the heading perhaps less distro-specific? Maybe that'll make the scope of the issue clearer.

craigloewen-msft commented 3 years ago

Serial support in WSL 2 is definitely on our radar! Our current and immediate roadmap is focusing on finalizing tools like --install, --mount, GUI app support, and GPU support, but we will be taking a look at prioritizing this issue again as we go ahead with scheduling in the future. I'll be sure to post any updates to this Github thread, thank you all for the feedback and interest.