New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't ping failing in both directions after updating to 10.0.20197.0 #5805
Comments
I tried adding a new distribution Debian to see if it hit the same issues and it did. I also noticed that this distribution is missing strace & uuidgen is this expected? |
Check your windows defender firewall rules. Your probably getting icmp echo requests blocked due to default behavior on private networks. |
I'm using Norton for my firewall and verified the settings I also disabled the firewall to see if it would help, it didn't. Also this was working and my Norton settings/software have not changed. The issue with ping failing when run from WSL2 appears to be the missing files reported in the strace log |
I also have this problem. I've upgraded to latest insider build. If I restart, wsl2 can access to the internet and ping to host machine. but after awhile (30m-1h) the problem occurred, I can not access internet or ping to host machine, but I can still access wsl via localhost. |
Same. And when I inspect Adapter Settings, I can not find any Hyper-V adapters. |
The same problem, wsl network does not work when the system wakes up from sleep. |
Same problem happening consistently to me as well. Dell XPS 15 7590 running latest insider build, if laptop sleeps/hibernates, when it resumes WSL2 cannot access internet whatsoever. Rebooting machine completely (non-sleep) brings connectivity back properly. |
Confirmed I am also seeing ping work right after boot (on Ubuntu 20.04 & 18.04) but then failing a little later (maybe 30 minutes or so) in my case system had not gone to sleep. I had recently connected to a VPN before the failure (not sure if these events are related). |
I have Kerio VPN network. Yesterday I reset Windows and have everything reinstall but the problem still occurred |
Immediately after reboot when I run Get-NetAdapter in powershell I get:
After I start VPN (Cisco AnyConnect in my case) I get:
So in the first listing vEthernet (WSL) is shown as "Up" and in the second is shown as "Disconnected" anyone know if such events are logged somewhere? |
I'm having the same issue on 20197. I do not use a VPN, but I have docker desktop with the WSL2 backend. A new build is available, |
I ended up uninstalling Docker and it seemed to help. But the problem persist simply by connecting and switching my active network connection WSL2 disconnects. |
The problem still exists on Build 20201. |
After playing trying out some other things, I seem to experience it more often now when I go from wireless to wired connections. At my desk I uses a docking station with ethernet and when I plug it in, WSL2 cannot access the network anymore unless I reboot. |
Yep, thats my exact problem. If I leave the cable connected and boot up.
WSL2 is fine. As soon as I switch to a wifi or any other connection it
creates the problem. If I boot up the laptop with no ethernet connection
and no wireless connection WSL2 is automatically disconnected. Even if I
was to add the ethernet connection after boot it will still not work.
|
Same issue here on Windows 20206.
and /etc/resolv.conf to
without success. |
|
I've found a disable/enable cycle on every Hyper-V Virtual Switch Extension Adapter in your network stack, restores network connectivity and DNS resolution to WSL 2. YMMV, but see my brief How-To. |
I am seeing this same behavior on 20211. After reboot, WSL2 and networking works fine. As soon as I start my OpenVPN client, WSL2 networking no longer works and WSL shows "Destination Host Unreachable" for all hosts. In addition to breaking WSL usage, it breaks vscode wsl integration and docker. I've had to uninstall docker in the interim.
The disable/enable cycling of the Hyper-V Virtual Switch Extension Adapters mentioned above does not work for me. Same behavior. |
With 20211 I continue to see the same disconnected "Hyper-V Virtual Ethernet Adapter" state occurring. The reset sequence does fix the state of the switch and sometimes I am then able to get network traffic in my Linux distributions but sometimes I have to reboot. I am able to use Cisco AnyConnect VPN and my Linux distributions still have a working network, |
Disabling/enabling the Hyper-V virtual adapter doesn't work for me on build 20211. I have to reboot Windows every damn time. :-/ |
Confirm, build 20211 has this problem and the Hyper-V enable/disable fix doesn't work for me either. |
Build 20215 and it still doesn't work. It has been three weeks (and 3 builds) for me, without DNS resolution. I've tried everything in my bag of tricks, and most of the work-arounds in this and four other threads with the same or similar issue. We need some kind of update on this, IMHO. |
Still having same issue. Not fix at all :( |
With build 20221 networking in WSL 2 is still whacked. Looks like they are working on it:
|
Updated to Win 10 Insiders build 20226 and today's (10/1/20) edge channel release of Docker Desktop Community 2.4.1.0 with docker engine 19.03.13, build 4484c46d9d, early this morning, and WSL 2 network connectivity and DNS name resolution is finally working again. Since then, hibernation while I was at lunch, returned and WSL 2 remains working without any issues. 🤞 |
I'm still having problems I just installed 20226 and networking was fine until I enabled VPN and that killed it. Some related discussion came to my notice today: I recently saw this blog post from a VPN developer about WSL2 leaking network traffic when using a VPN, and it seems likely that it affects Cisco AnyConnect. https://mullvad.net/en/blog/2020/9/30/linux-under-wsl2-can-be-leaking/ This seems pretty fundamental to WSL2, and since many are working from home over VPN, definitely beware. Some related issues in the WSL repository hint at this as well, so you may need to do some extra setup inside WSL2 for connecting to hosts. #5068 WSL2 , problem with network connection when VPN used (PulseSecure) #5068 |
This script was posted a couple days ago, and is the only thing that has worked to fix these issues for me. Anytime my WSL networking stops working, with the latest build, seems to only happen after VPN connection. Run this script, everything works again. I think the piece I was missing when I restarting LxssManager and the NetAdapters, was the Host Name Service (hns). YMMV
|
worked for me, tx a lot! |
This worked for me, thanks. |
for me too! Thanks @sergeivolodin |
Hi all, I tried @sc0ttwad3 's Disable-NetAdapter + Enable-NetAdapter without any success, but I got a permanent ping by setting the advanced property "RSS Profile" to "Closest Processor", but YMMV: Good luck! Post-Edit: I have same success disabling the wifi and some seconds later re-enabling it. |
only solution so far that worked. |
This bug hits Microsoft's Biggest Customers the MostCoincidence: DELL seems to be a common denominator. This may be simply a result of larger corporations using VPNs It's September 2023, this bug report was posted over 3 years ago and NOT FIXED. This bug ONLY affects WSL1 and WSL2 and hundreds of similar bug reports per year for 10+ years have been posted ALL WITH NO FIX. The people reading these reports also close them like it is not a bug, yet this bug is costing Microsoft BILLIONS as it affects ALL THE BIGGEST customers! I notice that I also have to start WSL2:Debian first (which then has no network) then start WSL2:Ubuntu then both get network, |
Environment
Steps to reproduce
In WSL2->Win dir
On WSL2:
cat /etc/resolv.conf (gave 172.31.0.1) then 'ping 'gave:
strace log attached and reported a number of issues
In Win->WSL2 dir
On WSL2 determine ip address using: "ip addr|grep eth0" on my system this gave 172.31.7.186
On PS7: ping <ip address determined in step 1>
I then get
I verified that sshd was running
strace_wsl_ubuntu_20.04.log
WSL logs:
Expected behavior
ping should complete normally in both directions
Actual behavior
ping failed in both directions
The text was updated successfully, but these errors were encountered: