git pull takes a long time; was fixed by turning off ipv6 using GIT_SSH_COMMAND="ssh -4"

[jcrben]

Windows Version

Windows 11 10.0.22631.3880 (23H2)

WSL Version

2.2.4.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

Linux version 5.15.153.1-microsoft-standard-WSL2 (root@941d701f84f1) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.37) #1 SMP Fri Mar 29 23:14:13 UTC 2024

Distro Version

Ubuntu-22.04

Other Software

No response

Repro Steps

Steps to Reproduce:

First off: I'm having trouble reliably reproducing this today. It was happening to me last night running ipv6 on WSL2 and fixed by disabling ipv6 - but today it's not happening even tho I'm connecting via ipv6 - and I'm confirming that ipv6 is being used via strace output like 271412 getsockname(3, {sa_family=AF_INET6, sin6_port=htons(60766), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "2601:648:8200:1c40::756b", &sin6_addr), sin6_scope_id=0}, [128 => 28]) = 0 (altho keep in mind I might be incorrectly reading these things).

Not using a vpn - this is my personal machine where I don't need to use a vpn.

This is my ~/.wslconfig:

[wsl2]
networkingMode=mirrored

My /etc/resolv.conf:

[boot]
systemd=true

[interop]
appendWindowsPath = false

[network]
generateResolvConf=false

1. Clone down a repo which can you pull from - mine is a pretty repo in gitlab
2. Run git pull
3. notice it takes a long time - over a minute
4. GIT_SSH_COMMAND="ssh -4" git pull returns as fast as expected

I turned off ipv6 because I noticed it was doing an ipv6 connection when I ran strace -v -s 1000 -f -o strace_output.txt git pull and then tail -f strace_output.txt in another terminal.

I had previously not noticed this lag issue because I had included kernelCommandLine=ipv6.disable=1 at someone's suggestion. But I recently discovered that this configuration was breaking docker desktop integration with my wsl2 ubuntu instance (see docker/for-win#13707 (comment)).

References:

• [WSL 2] Hangs forever on most network calls (like curl, git, etc.) #8358 - mine was not hanging forever, but seems similar in that people report disabling ipv6 helps
• WSL2 git is slow from gitlab #6602 - focused more on dns causes; this doesn't seem to be what was happening here
• Git pull hangs forever #985 - different issue/cause
• git pull takes a long time; fixed by turning off ipv6 using GIT_SSH_COMMAND="ssh -4" vscode#225344 (accidentally misfiled) - triggering a link to here on that issue

Expected Behavior

git pull should return the update or Already up to date. fairly quickly (not more than a couple seconds)

Actual Behavior

git pull takes a while to return

Diagnostic Logs

No response

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How 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 script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

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

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to wsl-gh-logs@microsoft.com with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Closed similar issues:

• Poor performance with WSL2 and Windows 11 (#11565), similarity score: 0.73
• WSL2 git is slow from gitlab (#6602), similarity score: 0.72
• [WSL2] git is very slow even on the same filesystem (#8588), similarity score: 0.71
• Git push is super slow even inside WSL file system (#9233), similarity score: 0.70

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[jcrben]

closing for now as I've had trouble replicating

[jcrben]

Reopening this as I just hit this again in another case - the vscode wsl server update which runs when you run code on wsl.

Attaching the logs - @OneBlue I'm hoping this is more complete than your average issue report. Let me know if there's anything I can add.

Reproduction steps - ~/.wslconfig and /etc/wsl.conf are the same as above.

Open WSL and run code . - see that it hangs - strace shows that it is using ipv6

Hangs for as long as I was willing to wait.

Disable ipv6 - I edited /etc/gai.conf and uncommented the precedence ::ffff:0:0/96 100 line.

Rerun code and notice that it works now.

WslLogs-2024-08-11_22-34-29.zip
WslNetworkingLogs-2024-08-11_22-41-55.zip

[github-actions]

Diagnostic information

Multiple log files found, using: https://github.com/user-attachments/files/16577731/WslLogs-2024-08-11_22-34-29.zip
.wslconfig found
Detected appx version: 2.2.4.0

[CatalinFetoiu]

@jcrben thanks for reporting the issue and attaching the logs and the strace output

the logs show that the IP you are trying to connect to at port 443 is 2620:1ec:bdf::69

I also see that your host machine only has local IPv6 connectivity, it does not have global IPv6 connectivity, which leads to connecting to global IPv6 address 2620:1ec:bdf::69 to fail - can you please confirm if you Windows machine has global IPv6 connectivity (e.g. does connecting to 2620:1ec:bdf::69, port 443 work on Windows) ?

[fractal80y]

Don't want to add irrelavant info. However faced same observed functioning behavior in WSL. I had ended up changing Port entry previously in /etc/ssh/ssh_config file, returning it back to 22 solved my case. Same outcome but most likely a different RC in amongst network config.

[jcrben]

@CatalinFetoiu in this case I did not have a working ipv6 connection. Thanks for digging in, you can close this