search

microsoft / WSL

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

localhost:PORT from windows host no longer gets handled by process running in WSL2 #8679

Closed mwidmann closed 2 years ago

mwidmann commented 2 years ago

Version

Microsoft Windows [Version 10.0.25169.1000]

WSL Version

Kernel Version

5.15.57.1

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

Expected Behavior

Whatever is running on localhost:3000 in WSL is getting delivered to the Browser requesting it.

Actual Behavior

Edge get's an ERR_CONNECTION_REFUSED error.

Accessing through the IP address of eth0 with the port works. So f.e. http://localhost:3000 or http://127.0.0.1:3000 fail, but http://172.25.170.221:3000 works.

This worked until this morning when I updated to the latest version (0.65.1) in the store.

Diagnostic Logs

No response

benhillis commented 2 years ago

Thanks for reporting. @pmartincic could you please take a look?

mickdewald commented 2 years ago

Maybe this has something do with that: I cannot reach my Kubernetes cluster build with KinD anymore. I also tested the Kubernetes cluster from Docker Desktop

Suddenly, I got (for Docker Desktop) The connection to the server kubernetes.docker.internal:6443 was refused - did you specify the right host or port? or for the KinD cluster The connection to the server 127.0.0.1:30000 was refused - did you specify the right host or port?

It worked perfectly for months. The only thing changed was a Windows Update with update of WSL to 0.65.1

❯ wsl --version
WSL version: 0.65.1.0
Kernel version: 5.15.57.1
WSLg version: 1.0.41
MSRDC version: 1.2.3213
Direct3D version: 1.601.0
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22622.450
olivierchatry commented 2 years ago

Same here, minikube cannot ssh to it container anymore. I can SSH to it from a "normal" windows prompt, but not from WSL linux distro. Happen since the last update I got this morning :

WSL version: 0.65.1.0
Kernel version: 5.15.57.1
WSLg version: 1.0.41
MSRDC version: 1.2.3213
Direct3D version: 1.601.0
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22622.450
ghost commented 2 years ago

/logs

ghost commented 2 years ago

Hello! Could you please provide more logs to help us better diagnose your issue?

To collect WSL logs, download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The scipt will output the path of the log file once done.

Once completed please upload the output files to this Github issue.

Click here for more info on logging

Thank you!

benhillis commented 2 years ago

Are you guys by chance using a private kernel? Could you share the output of cat /proc/version?

mickdewald commented 2 years ago 
❯ cat /proc/version
Linux version 5.15.57.1-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Wed Jul 27 02:20:31 UTC 2022

Are you guys by chance using a private kernel? Could you share the output of cat /proc/version?

I use the default Ubuntu 20.04 image

I will provide logs later, when I am home

felpasl commented 2 years ago

uninstalling 10.0.22622.450 on Windows Update>Update history>Uninstall updates doesn't fix remain the message

The connection to the server kubernetes.docker.internal:6443 was refused - did you specify the right host or port?

I'm trying to find an option to downgrade wsl back to [0.64.0]

Versão do WSL: 0.65.1.0
Versão do kernel: 5.15.57.1
Versão do WSLg: 1.0.41
Versão do MSRDC: 1.2.3213
Versão do Direct3D: 1.601.0
Versão do DXCore: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows versão: 10.0.22622.440

WslLogs-2022-08-03_16-15-51.zip

on WSL Ubuntu:

on Windows Host:

NotTheDr01ds commented 2 years ago

Just an additional data point that I am not able to reproduce after installing 0.65.1 on Windows 11 non-Insider (10.0.22000.795). I installed from the Releases page using Add-AppxPackage in an Administrative PowerShell:

I can now reproduce in Windows 11 GA with 0.65.1 based on @mwidmann's updated description.

$ $env:WSL_UTF8=1
$ wsl --status | clip.exe
Default Distribution: Ubuntu-22.04
Default Version: 2
WSL version: 0.65.1.0
Kernel version: 5.15.57.1
WSLg version: 1.0.41
MSRDC version: 1.2.3213
Direct3D version: 1.601.0
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.795

In Ubuntu 22.04:

python3 -m http.server

And can browse in Edge to localhost:8000 and view the directory contents. Also tried with port 3000, which worked as well.

So perhaps it's something else in Insider causing the issue rather than the WSL update? Or perhaps an interaction between the two.

felpasl commented 2 years ago

I'm using Insider back to 22622.450, the connection from windows to localhost:80 hosted in kubernetes WSL2 "Docker Desktop" worked.

from WSL2 Ubuntu docker ps worked

from WSL2 Ubuntu kubectl get namespaces doesn't work

from windows Powershell kubectl get namespaces worked

i'm trying to export my wsl Ubuntu distro, to uninstall wsl from windows, and try reinstall wsl without the Preview, in last scenario start work again in windows powershell until solution or work around was found 😥

mickdewald commented 2 years ago

I'm using Insider back to 22622.450, the connection from windows to localhost:80 hosted in kubernetes WSL2 "Docker Desktop" worked.

from WSL2 Ubuntu docker ps worked

from WSL2 Ubuntu kubectl get namespaces doesn't work

from windows Powershell kubectl get namespaces worked

i'm trying to export my wsl Ubuntu distro, to uninstall wsl from windows, and try reinstall wsl without the Preview, in last scenario start work again in windows powershell until solution or work around was found 😥

I can confirm the same behavior. I can also add, that I installed a new WSL distro Ubuntu 18.04 and got the same behavior with the freshly installed distro.

ghost commented 2 years ago

Ahhhh, this helps. I read the original bug description as saying that localhost:port was inaccessible from the windows host.

I'm using Insider back to 22622.450, the connection from windows to localhost:80 hosted in kubernetes WSL2 "Docker Desktop" worked.

from WSL2 Ubuntu docker ps worked

from WSL2 Ubuntu kubectl get namespaces doesn't work

from windows Powershell kubectl get namespaces worked

i'm trying to export my wsl Ubuntu distro, to uninstall wsl from windows, and try reinstall wsl without the Preview, in last scenario start work again in windows powershell until solution or work around was found 😥

DmytryEmery commented 2 years ago

I'm trying to find an option to downgrade wsl back to [0.64.0]

Any luck on this? [0.65.1] has broken Kind cluster.

Everything (docker desktop, kind) latest version, but since yesterday when this got updated it doesn't work, even with clean install.

Just as a work around: just using docker destop without WSL engine, everything still works.

benhillis commented 2 years ago

@DmytryEmery - I'd suggest downloading a previous release from the github releases page.

DmytryEmery commented 2 years ago

@benhillis thanks! just to confirm reverting to 0.64.0 resolved the issue for me

benhillis commented 2 years ago

While debugging this locally we have pushed https://github.com/microsoft/WSL/releases/tag/0.65.2 which will revert to the previous behavior.

mwidmann commented 2 years ago

~Sadly the update was installed before I could get the logs, but I can confirm that with this version, the described issues are gone.~

I have to revert this. While the first couple of requests worked fine, it is back to ERR_CONNECTION_REFUSED now.

Tried on ports 8080 and 4400. localhost and 127.0.0.1 don't work. The IP Address eth0 has in ubuntu instance can be used to connect.

I ran the collect-wsl-logs.ps1 command and have the following logs. Hope those help to identify the issue. WslLogs-2022-08-04_08-02-22.zip

BTW, the machine is already updated to the latest DEV Insider build Microsoft Windows [Version 10.0.25174.1000]

This is what wsl --version outputs:

WSL-Version: 0.65.2.0
Kernelversion: 5.15.57.1
WSLg-Version: 1.0.41
MSRDC-Version: 1.2.3213
Direct3D-Version: 1.601.0
DXCore-Version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows Version: 10.0.25174.1000

and this is the output of cat /proc/version inside my Ubuntu installation:

Linux version 5.15.57.1-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Wed Jul 27 02:20:31 UTC 2022
Tychoblood commented 2 years ago

@benhillis thanks! just to confirm reverting to 0.64.0 resolved the issue for me

Can you explain how you did it ? Downloaded the packages and launched the installer but it wouldn't finish. Tried in Powershell via this command : Add-AppPackage -path "C:\Users\xxxxxx\Downloads\Microsoft.WSL_0.64.0.0_x64_ARM64.msixbundle" but to no avail. It states that the superior version is already installed and so cant downgrade...

Having the same problem after this night update , and of course the day it is most needed (merge and review for client project release...)

~Sadly the update was installed before I could get the logs, but I can confirm that with this version, the described issues are gone.~

I have to revert this. While the first couple of requests worked fine, it is back to ERR_CONNECTION_REFUSED now.

Tried on ports 8080 and 4400. localhost and 127.0.0.1 don't work. The IP Address eth0 has in ubuntu instance can be used to connect.

I ran the collect-wsl-logs.ps1 command and have the following logs. Hope those help to identify the issue. WslLogs-2022-08-04_08-02-22.zip

BTW, the machine is already updated to the latest DEV Insider build Microsoft Windows [Version 10.0.25174.1000]

This is what wsl --version outputs:

WSL-Version: 0.65.2.0
Kernelversion: 5.15.57.1
WSLg-Version: 1.0.41
MSRDC-Version: 1.2.3213
Direct3D-Version: 1.601.0
DXCore-Version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows Version: 10.0.25174.1000

and this is the output of cat /proc/version inside my Ubuntu installation:

Linux version 5.15.57.1-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Wed Jul 27 02:20:31 UTC 2022

I have the exact same problem, it works for a few http/https requests and then back to ERR_CONNECTION_REFUSED afterwards

mwidmann commented 2 years ago

@benhillis thanks! just to confirm reverting to 0.64.0 resolved the issue for me

Can you explain how you did it ? Downloaded the packages and launched the installer but it wouldn't finish. Tried in Powershell via this command : Add-AppPackage -path "C:\Users\xxxxxx\Downloads\Microsoft.WSL_0.64.0.0_x64_ARM64.msixbundle" but to no avail. It states that the superior version is already installed and so cant downgrade...

Having the same problem after this night update , and of course the day it is most needed (merge and review for client project release...)

The update was just offered to me through the Windows Store. That's why it was faster than my logs gathering.

mwidmann commented 2 years ago

This is getting stranger and stranger. It appears that the problems start when a second port is opened with the same process. Running one node process on port 8080 works, starting a second one on port 4400 produces the ERR_CONNECTION_REFUSED. Same with the simple python webserver. Running python3 -m http.server works, but starting a second instance python3 -m http.server 8080 breaks both.

Here's a new set of logs... WslLogs-2022-08-04_08-50-11.zip

olivierchatry commented 2 years ago

Still the same issue with minikube using 0.65.2.

Forcing downgrade to 0.64.0 fixed the issue.

Sidenote, to downgrade:

  1. download the package from github https://github.com/microsoft/WSL/releases/download/0.64.0/Microsoft.WSL_0.64.0.0_x64_ARM64.msixbundle
  2. Open a powershell prompt
  3. On the prompt, navigate to folder in which you downloaded the file
  4. then type ( or copy paste ) : Add-AppxPackage -Path .\Microsoft.WSL_0.64.0.0_x64_ARM64.msixbundle -ForceUpdateFromAnyVersion -ForceApplicationShutdown
hf35 commented 2 years ago

Have the same issue with opening localhost and 127.0.0.1 on diffrent ports. It can work with localhost:3000, but doesn't work on localhost:3020 or vise versa. Both 0.65.1 and 0.65.2 have this issue.

Downgrade to 0.64.0 is fixed problem

Added logs (while launched server and tryed to get it from Windows) WslLogs-2022-08-04_13-39-38.zip

hf35 commented 2 years ago

One more thing react application doesn't work on localhost:3000, but "nc -l 3000" - worked correctly on localhost:3000

Tychoblood commented 2 years ago

Still the same issue with minikube using 0.65.2. Forcing downgrade to 0.64.0 fixed the issue. Sidenote, to downgrade, download the package from github then, on a powershell prompt : powershell Add-AppxPackage -Path .\Microsoft.WSL_0.64.0.0_x64_ARM64.msixbundle -ForceUpdateFromAnyVersion -ForceApplicationShutdown

I can confirm this work, I was just missing the ForceUpdate part. Downgrading to 0.64.0 also fixed the issue , whereas the 0.65.2 would work for a few requests and then no more, with ERR_CONNECTION_REFUSED http status.

zed76r commented 2 years ago

0.65.2 not work for me

felpasl commented 2 years ago

0.65.2 doesn't work, thx @olivierchatry, reverting is an solution, but an --upgrade "version" or some type of downgrade procedure in docs will be easy.

mickdewald commented 2 years ago

Another thing I noticed is that my computer freezes now regularly when I do wsl --shutdown. This never happened before in previous versions. It's a complete freeze and I can't do anything. Have to unplug the A/C connector.

EDIT: I also downgraded to 0.64 and everything works again. Kubernetes in WSL is reachable again. No sudden connection lost with react apps and no freeze during WSL --shutdown

hf35 commented 2 years ago

Another thing I noticed is that my computer freezes now regularly when I do wsl --shutdown. This never happened before in previous versions. It's a complete freeze and I can't do anything. Have to unplug the A/C connector.

EDIT: I also downgraded to 0.64 and everything works again. Kubernetes in WSL is reachable again. No sudden connection lost with react apps and no freeze during WSL --shutdown

Btw, i had the same complete freezes after "WSL --shutdown" on 0.65...

benhillis commented 2 years ago

Taking another look, the revert should have fixed the issue...

benhillis commented 2 years ago

@hf35 - I'll try to repro locally, but it looks like 0.65.2 may not have the full revert. Taking a look.

benhillis commented 2 years ago

Ok I sorted this out, I tagged the wrong commit. Pushing a new build (0.65.3) here shortly.

benhillis commented 2 years ago

@hf35 - coudl you please file a new bug for that issue? I suspect this is vgpu related.

benhillis commented 2 years ago

https://github.com/microsoft/WSL/releases/tag/0.65.3

swichers commented 2 years ago

@benhillis Should we be seeing 0.65.3 as an update for insiders at this point, or is that for manual install?

zed76r commented 2 years ago

@benhillis Should we be seeing 0.65.3 as an update for insiders at this point, or is that for manual install?

image

hf35 commented 2 years ago

@benhillis everyhing is ok on 0.65.3 with localhost

@hf35 - coudl you please file a new bug for that issue? I suspect this is vgpu related.

About freezes? I am not sure, how i can save log, because after shutdown command - my pc is completly freeze and and can't press button to collect logs

nunix commented 2 years ago

I went through podman/docker desktop/rancher desktop/k3d/kind with 0.65.3 and as far as I can tell, it's fixed now.

Thank you @benhillis and team for the fast fix, really appreciated

mickdewald commented 2 years ago

I haven't tested it myself yet with the new version but I can only say also thanks especially for the extremely fast response time and fixes. Very much appreciated.

benhillis commented 2 years ago

Thanks everyone for the kind words, we're working on a fix here because the new localhost behavior is really neat (minus this bug).

@hf35 - please file a new issue, that is unrelated.

Ankit1598 commented 2 years ago

I downgraded wsl, rolledback windows update, tried all the combinations possible but nothing works, when I run any of my WebApp (React, Next, Nuxt, etc) and try to access https://localhost:3000, I keep getting ERR_CONNECTION_RESET

WSL Versions tried: 0.65.3, 0.64.0, 0.61.8

$ ver Microsoft Windows [Version 10.0.25169.1000]

$ wsl.exe --status Default Distribution: Ubuntu-20.04 Default Version: 2 WSL version: 0.65.3.0 Kernel version: 5.15.57.1 WSLg version: 1.0.41 MSRDC version: 1.2.3213 Direct3D version: 1.601.0 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.25169.1000

onomatopellan commented 2 years ago

@Ankit1598 Make sure you are not hitting https://github.com/microsoft/WSL/issues/5575

olivierchatry commented 2 years ago

I'm quite sure it is unrelated to this issue. Maybe you should try to use http instead of https ?

filippomc commented 1 year ago

The same issue appears on wsl 1.1.0 (now installed by default on insider previews). Downgrading to 1.0.3 fixed for me

olivierchatry commented 1 year ago

Yup, same for me.

forberg commented 1 year ago

Same with WSL 1.1.0 for me. Works if i downgrade to 1.0.3. Maybe create a new issue? Seems to be some localhost related updates in 1.1.0: https://github.com/microsoft/WSL/releases/tag/1.1.0

Updated issue here: https://github.com/microsoft/WSL/issues/9508

ghost commented 1 year ago

Back from the dead!

Sorry for the inconvenience. This issue you're experiencing in 1.1.0 is currently being worked on and tracked at #9508 This issue, 8679, tracked other problems with the relay.

felpasl commented 1 year ago

same behavior again, downgraded from 1.1.2 to 1.0.3 and worked:

Add-AppxPackage -Path .\Microsoft.WSL_1.0.3.0_x64_ARM64.msixbundle -ForceUpdateFromAnyVersion -ForceApplicationShutdown

Persedes commented 1 year ago

Popped up for the first time up after upgrading to 1.1.3:

wsl --version
WSL version: 1.1.3.0
Kernel version: 5.15.90.1
WSLg version: 1.0.49
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.1574
ghost commented 1 year ago

@persedes, I just realized that this bug was tracking code that was reverted. Could you open a new bug and post logs? Thanks!

I'm going to lock this thread to direct people elsewhere.