Open david-dumke opened 5 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.
Still using wsl1 because of this and faster host-shared file system.
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.
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.
@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.
I'm eagerly waiting for a proper fix for this issue. I hope MS will fix this soon.
Frustrated that I cannot do development of the SMS integration for homeassistant with WSL 2.
Disappointed after scanning through here that I had to downgrade to WSL1, currently using Ubuntu 20.04.
BUMP! For all the reasons other people have mentioned on this thread, with a specific echo of what @daviddecobee said!!
Please Microsoft make this a high priority...
Stuck in WSL 1 land also since I rely on WSL for doing microcontroller development and rely on USB communication with physical hardware.
This issue happens in other distros as well (e.g openSUSE 15.1/15.2).
bump
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'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!
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.
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
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
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.
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.
Is there a way to follow how far the WSL team has gotten in implementing USB/COM ports for WSL2 since July 2019?
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 :)
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.
Bump!!!
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.
please, pretty please!
WSL's IO performance is horribly low.If WSL2 does not support serial, it can only switch to linux completely
I wonder if a tcp/serial bridge running on the host would help.
@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
@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_
Is there any plans to make this work?
Maybe Microsoft hasn’t figured it out yet
????????
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.
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.
Bump!
Actually it's very important and necessary for embedded software debug. This issue is fatal to WSL2!!!!
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.
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
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!
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.
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.
The difficulty is likely due to WSL2 sitting on top of virtualization, unlike WSL1.
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.
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...
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
Wonder if @craigloewen-msft could let us know if this is even remotely on their radar :)
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
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.
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.
Your Windows build number: Microsoft Windows [Version 10.0.18932.1000]
What you're doing and what's happening:
What's wrong / what should be happening instead: This works under WSL1 flawlessy, it no longer works in WSL2 in WSL2 we can clearly see it is not connected or configured /dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3