Closed CyrusNajmabadi closed 1 month ago
This work for me: set MTU to 1350 (same as VPN interface): sudo ifconfig eth0 mtu 1350
I wanted to go ahead and also say this fixed my SSH issue as well as my git cloning issue. I set my MTU to match the VPN interface that I'm attempting to SSH over (1400) and it worked afterwards.
Ok. So updating my wifi chipset drivers fixed the issue. In case anyone else runs into the above, the drivers i updated to were found here: https://downloadcenter.intel.com/download/28794/Windows-10-Wi-Fi-Drivers-for-Intel-Wireless-Adapters?product=99446
@therealkenc I think i'm personally back in a good space. I'm guessing there was some sort of hyperv incompatibility with those drivers. Given that it seems to be working now, i'm personally ok if you want to close this. Or, if you want me to collect more info, def let me know!
A million thanks! Still works till today with the link you provided. Just curious why the 'PC manager' shipped with my laptop wouldn't keep the chipset driver updated yet says it's 'updated' :/
The solutions of this issue feel a lot of hocus-pokus, copy-pasty "it works in my machine"! but no explanations. I'll try to address that, and hopefully help the ones who have had no luck so far.
Until this issue I never had heard of MTU, and it was hard for me to believe that was the cause, well it is.
Try upgrading your drivers first, that thidn't work for me.
First open a PowerShell prompt and type:
netsh interface ipv4 show subinterface
You will get an output like the following:
MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
4294967295 1 0 5974969 Loopback Pseudo-Interface 1
1500 1 2678641808 213293706 Wi-Fi
1500 5 0 0 Local Area Connection* 1
1500 5 0 0 Local Area Connection* 2
1500 1 0 529702 vEthernet (Default Switch)
1300 1 2106 509236 vEthernet (WSL)
1200 1 553027168 20290571 Local Area Connection* 13
1500 1 0 22759124 VirtualBox Host-Only Network #3
1500 5 0 0 Bluetooth Network Connection 4
The key is in the *Local Area Connection 13 MTU (The name and value can change from machine to machine), that is the VPN interface**. In my case it's 1200 which is why
set MTU to 1350 (same as VPN interface): sudo ifconfig eth0 mtu 1350
didn't work for me... and I didn't know how to get the VPN Interface MTU.
(I also hated to install ifconfig which is deprecated in favor of ip).
Now that we know, you can change the VPN MTU from Windows it in a PowerShell with Elevated Privileges,
netsh interface ipv4 set subinterface "Local Area Connection* 13" mtu=1400 store=persistent
If you want to skip the next step, you can set it to 1500, but you are leaving no room for the VPN to wrap the packets, for example I have had trouble with Github because of setting it to 1500.
Then, inside your WSL2 distro, you can check your current MTU values with:
❯ ip addr | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
We care about eth0 (the virtual ethernet connection to Windows), you have to set a matching MTU to where you left it in the previous step.
sudo ip link set eth0 mtu 1400
Sadly both settings get resetted every time you start a new VPN session, or restart the WSL2, or even switch from WLAN to LAN.
There are ways to work around and alleviate the hassle, but that's beyond the scope of this issue.
I hope this helps much cleverer people into coming up with a more sustainable solution, this is good enough for me, for now.
Hopes this clarifies a bit why the solution works, there's still a lot I don't get.
@kangaroody You should be able to accomplish the same with
ip link set dev eth0 mtu 1350
. The ip tool is taking the place of ifconfig in many distributions. Having said that, I haven't tested this yet. It seems odd to me since matching mtu is usually the goal, but I'll give the hack a go and find out.
Thank’s a bunch❤️
Ok. So updating my wifi chipset drivers fixed the issue. In case anyone else runs into the above, the drivers i updated to were found here: https://downloadcenter.intel.com/download/28794/Windows-10-Wi-Fi-Drivers-for-Intel-Wireless-Adapters?product=99446
@therealkenc I think i'm personally back in a good space. I'm guessing there was some sort of hyperv incompatibility with those drivers. Given that it seems to be working now, i'm personally ok if you want to close this. Or, if you want me to collect more info, def let me know!
THIS WAS MAGIC :)
Manually update Wi-Fi drivers, problem fixed!
Update driver using auto search in device manager resulted in "The best driver is already installed". Ignore that message, and just get the latest Intel WiFi package from the link above.
To think that in 2021, a fix from 2019 is still required to use SSH on WSL2.
But… I use cabled Ethernet 🤯
But… I use cabled Ethernet 🤯
Aside from just Ethernet/WiFi Adapter drivers, I encountered this issue when connected to a VPN. The combination of VPN and network drivers didn't work out super well. To solve the issue, I had to follow the above recommendation, and set the MTU of the WSL instance lower than the MTU of the VPN network adapter.
@baamenabar has a great comment above (https://github.com/microsoft/WSL/issues/4253#issuecomment-849336363) that explains how to check the MTU of your interfaces. You'll notice in the example output above that there is a network card with an MTU of 1300 and on with an MTU of 1200. The standard MTU of an interface is normally 1500, so if your WSL interface is set to an MTU higher than the interface that you're using for internet, you can run into the issue mentioned here. They then show you how to use netsh to set the MTU of the WSL interface to match.
Indeed, I wrote my comment just to underline that it's not possible that this issue is directly related to WiFi network driver or that it's the root cause. I use a VPN and simply setting MTU of WSL network interface (eth0) to 1350 solves the issue.
Hello, now drop in this topic... after reinstalling my system to Windows 11. I've been using WSL for a while and I've never had problems with the network. And after reinstalling the whole system was facing problem downloading packages and accessing internet via WSL.
In summary: I ended up discovering that there was an interference in my network, as I use Wifi to access the Internet, the ethernet cable was connected to my local storage for backups. After removing this ethernet cable connected to the storage, everything worked, I believe it is a conflict between adapters, so this is a suggestion for those who are facing this type of problem with Wifi + Cable.
Try to check if you are not using 2 networks, if you are, try to use only the internet (close and open the terminal again) and check if it works.
The solutions of this issue feel a lot of hocus-pokus, copy-pasty "it works in my machine"! but no explanations. I'll try to address that, and hopefully help the ones who have had no luck so far.
Until this issue I never had heard of MTU, and it was hard for me to believe that was the cause, well it is.
- I'm having isues when my Pulse Secure VPN is connected and I'm trying to connect to the internal self-hosted Gitlab.
- SSH traffic to the regular internet is fine.
- I'm using WSL2 Ubuntu 20.04, if I drop it to WSL1, all works as expected (Same for Debian).
Try upgrading your drivers first, that thidn't work for me.
First open a PowerShell prompt and type:
netsh interface ipv4 show subinterface
You will get an output like the following:
MTU MediaSenseState Bytes In Bytes Out Interface ------ --------------- --------- --------- ------------- 4294967295 1 0 5974969 Loopback Pseudo-Interface 1 1500 1 2678641808 213293706 Wi-Fi 1500 5 0 0 Local Area Connection* 1 1500 5 0 0 Local Area Connection* 2 1500 1 0 529702 vEthernet (Default Switch) 1300 1 2106 509236 vEthernet (WSL) 1200 1 553027168 20290571 Local Area Connection* 13 1500 1 0 22759124 VirtualBox Host-Only Network #3 1500 5 0 0 Bluetooth Network Connection 4
The key is in the _Local Area Connection 13 MTU_* (The name and value can change from machine to machine), that is the VPN interface. In my case it's 1200 which is why
set MTU to 1350 (same as VPN interface): sudo ifconfig eth0 mtu 1350
didn't work for me... and I didn't know how to get the VPN Interface MTU.
(I also hated to install ifconfig which is deprecated in favor of ip).
Now that we know, you can change the VPN MTU from Windows it in a PowerShell with Elevated Privileges,
netsh interface ipv4 set subinterface "Local Area Connection* 13" mtu=1400 store=persistent
If you want to skip the next step, you can set it to 1500, but you are leaving no room for the VPN to wrap the packets, for example I have had trouble with Github because of setting it to 1500.
Then, inside your WSL2 distro, you can check your current MTU values with:
❯ ip addr | grep mtu 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000 3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000 4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
We care about eth0 (the virtual ethernet connection to Windows), you have to set a matching MTU to where you left it in the previous step.
sudo ip link set eth0 mtu 1400
Sadly both settings get resetted every time you start a new VPN session, or restart the WSL2, or even switch from WLAN to LAN.
There are ways to work around and alleviate the hassle, but that's beyond the scope of this issue.
I hope this helps much cleverer people into coming up with a more sustainable solution, this is good enough for me, for now.
Hopes this clarifies a bit why the solution works, there's still a lot I don't get.
Your solution to the problem was similar to mine, however I changed the Ethernet MTU inside on my WSL2 to the same numbering I saw in windows power shell(Ethernet WSL), and that way it worked for me :)
Ok. So updating my wifi chipset drivers fixed the issue. In case anyone else runs into the above, the drivers i updated to were found here: https://downloadcenter.intel.com/download/28794/Windows-10-Wi-Fi-Drivers-for-Intel-Wireless-Adapters?product=99446
@therealkenc I think i'm personally back in a good space. I'm guessing there was some sort of hyperv incompatibility with those drivers. Given that it seems to be working now, i'm personally ok if you want to close this. Or, if you want me to collect more info, def let me know!
thank you so much!
I just encountered the same issue - but here is the strange thing (and I don't know if it is by design or not), but I use ExpressVPN and if you are connected to that, WSL will not work. Any ideas how to fix that?
Great report; you've tried a number of sensible things here. This is going to be a case of finding the external variable; and I am unfortunately not guessing it right away. What makes this one especially tricky is you've started clean. Needless to say you can do a
https://
git clone from a clean Win 10 install, clean Ubuntu, or you know heads would roll...So what's the variable....
There are plenty of hits on your
GnuTLS recv error
but I'm not loving the answers (and lack thereof) being given. None of them are going to help answer how you are stuck out of a clean install.Confirm: There wasn't a "installed my usual VPN / AV / proxy / etc" software somewhere inbetween steps 1/2/3/4 at the top. [Take as given "no" but it needs asking.]
One thing you can try while I sleep on it is install the Ubuntu-18.04 (contrast Ubuntu) version from the store. First thing out of the gate after you convert WSL2:
$ sudo apt update $ sudo apt upgrade $ sudo apt install git openssl ca-certificates $ git clone https://github.com/therealkenc/wsl-umask-toy
We can cross the
ssh
bridge (which has more paths to failure) later. Fact I'm drawing a total blank on how theapt upgrade
would take but not thegit clone
. If theapt upgrade
failed at least we could point finger "networking problems".So there is something going wrong with wsl2 here...
Indeed. But that it is working for you on WSL1 unfortunately isn't hinting at the external variable that is causing a simple
git clone
to fail for you on WSL2.
This worked for my WSL1 machine. Thank you so much!
This work for me: set MTU to 1350 (same as VPN interface): sudo ifconfig eth0 mtu 1350
This trick solved to me! Windows 11, using a Gitlab on my company intranet through a vpn.
Thanks a lot!
This only happens for me during the day. Late at night, about midnight, it does not. (Testing an Ansible role with Molecule via docker.)
Configuring /etc/resolv.conf to only contain nameserver 8.8.8.8
in WSL and connecting the laptop directly via ethernet cable to the LTE router seems to have solved this for me.
WSL should probably set the MTUs to match the adapters it is virtualising.
@baamenabar isn't "vEthernet (WSL)" the one you should be looking at? In this case it also has an MTU of 1300.
If you have a VPN installed, it has reduced the MTU in order to give it space to wrap the packets (the MTU on the general Internet is 1500). Raising the MTU back up will degrade your performance due to all your VPN traffic getting split. You always want to instead reduce the MTU inside WSL to match.
I tried WSL for the first time today and immediately hit this issue. I'm using wired Ethernet with no VPN.
In powershell, I see:
PS C:\Users\surfe\gitrepos> netsh interface ipv4 show subinterface
MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
4294967295 1 0 302073 Loopback Pseudo-Interface 1
1500 5 0 0 Wi-Fi
1500 1 4024581386 40317294 Ethernet
1500 5 0 0 Bluetooth Network Connection
1500 5 0 0 Local Area Connection* 3
1500 5 0 0 Local Area Connection* 12
1500 1 1212160 32172912 vEthernet (WSL)
PS C:\Users\surfe\gitrepos>
In Debian, I see:
$ ip link
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:15:5d:92:60:f7 brd ff:ff:ff:ff:ff:ff
Git clone takes forever and/or fails in Debian. Works fine in Windows.
Isso funciona para mim: defina MTU para 1350 (o mesmo que a interface VPN): sudo ifconfig eth0 mtu 1350
me too
This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.
Thank you!
Never got it to work on my machine. Instead, I uninstalled Windows and installed Linux.
Important: these steps work from Wsl1. They don't work on wsl2. So something seems to have changed here for the worse.
Specifically: I've been unable to clone from github using wsl2. I've completely wiped my windows machine and the issue still reproes. Here are the steps i've taken:
I then upgraded to wsl2 using:
Logging into Ubuntu, i did the following to update/upgrade Ubuntu:
I then created an ssh key like so:
I then uploaded this key to my github account.
I then tried to clone like so:
I've been completely unable to get cloning to work.
Please use the following bug reporting template to help produce issues which are actionable and reproducible, including all command-line steps necessary to induce the failure condition. Please fill out all the fields! Issues with missing or incomplete issue templates will be closed.
If you have a feature request, please post to the UserVoice.
If this is a console issue (a problem with layout, rendering, colors, etc.), please post to the console issue tracker.
Important: Do not open GitHub issues for Windows crashes (BSODs) or security issues. Please direct all Windows crashes and security issues to secure@microsoft.com. Ideally, please configure your machine to capture minidumps, repro the issue, and send the minidump from "C:\Windows\minidump\".
Please fill out the below information:
ver
at a Windows Command Prompt)Microsoft Windows [Version 10.0.18922.1000]
Trying to clone a github repo produces:
Cloning should actually succeed.
some_command
is failing, then runstrace -o some_command.strace -f some_command some_args
, and link the contents ofsome_command.strace
in a gist here).https://gist.github.com/CyrusNajmabadi/17ca72e2018196185fd885a84e5c6011
Any help would be very appreciated.