Open jtgoral opened 10 months ago
Hi I'm an AI powered bot that finds similar issues based off the issue title.
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. Thank you!
Note: You can give me feedback by thumbs upping or thumbs downing this comment.
I forgot to add that it happened on 2 windows computers after the same update.
When running from Windows Power Shell ping works ok. From WSL2 no more.
Are you sure this has anything to do with windows update? What do you have in /etc/nsswitch.conf
?
Thank you @jtgoral. Can you try to put the following in %userprofile%/.wslconfig, then run: "wsl.exe --shutdown" to apply them:
[wsl2]
dnsTunneling=false
And see if that solves the issue ?
Yes, Adding the line to .wslconfig solved the problem on both computers:
jacek@okno-galaxy:/mnt/c/Users/jacek/public_html/beer/beersmith2$ ping okno-t320.local PING okno-t320.local (192.168.68.115) 56(84) bytes of data. 64 bytes from 192.168.68.115 (192.168.68.115): icmp_seq=1 ttl=63 time=14.9 ms 64 bytes from 192.168.68.115 (192.168.68.115): icmp_seq=2 ttl=63 time=16.4 ms
Yes, it was caused by a Windows update. All tries to use avahi connections stopped working right after the update on two Windows boxes.. Computers I connect from WSL (*.local) are FreeBSD and EndeavourOS Linux. Modifying .wslconfig as suggested fixed the problem and my git repository, ssh and VNC servers are available again when using .local instead of IP addresses.
i also had this issue on the most recent version of Windows 11 Pro (as of 2024-06-14). the suggested fix worked for me as well.
I can confirm that the workaround from @OneBlue worked for me too.
I can also confirm that the upgrade broke this for me and what @OneBlue suggested fixed the issue.
I tried adding that configuration value inside the distribution's /etc/wsl.conf
file and it didn't work, so adding that configuration on %userprofile%/.wslconfig
in the host machine is the only way.
I used to be able to resolve names in the .local domain, but recently I encountered this issue. For my case, the following fixes were necessary:
# the workaround from @OneBlue
[wsl2]
dnsTunneling=false
# /etc/nsswitch.conf
-hosts: files mdns4_minimal [NOTFOUND=return] dns
+hosts: files dns mdns4_minimal
(I am using WSL2 in NAT mode not Mirrored mode.)
I just re-discovered this problem and fix of disabling DNS tunneling. It seems like a pretty significant regression in WSL2, for .local
domains to just stop working in the default configuration. Is this a temporary bug in the DNS tunneling implementation, will it eventually start working with mDNS again?
@CatalinFetoiu & @keith-horton - could you please take a look?
I "solved" this by running a perl DNS server on a centos host on the same network, which calls avahi-resolve -n whatever.local
and outputs the IP, which it gives to "bind" (named) which is set up as a caching nameserver. Annoying I had to do this, but I have a lot of WSL machines and this was really getting in the way of my IoT development...
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
// see also https://bind9.readthedocs.io/en/latest/chapter6.html
//
options {
listen-on port 53 { 192.168.1.66; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
secroots-file "/var/named/data/named.secroots";
recursing-file "/var/named/data/named.recursing";
allow-query { localhost; 192.168.1.0/24; };
recursion yes;
dnssec-validation no;
managed-keys-directory "/var/named/dynamic";
geoip-directory "/usr/share/GeoIP";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
/* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
include "/etc/crypto-policies/back-ends/bind.config";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
zone "local" {
type forward;
forward only;
forwarders { 127.0.0.1; };
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
thanks for reporting the issue
we have updated the docs to include details about how to resolve .local names in WSL. Please refer to https://learn.microsoft.com/en-us/windows/wsl/troubleshooting#resolve-local-names-in-wsl
let us know if you have any questions
tl;dr: the new docs suggest turning off DNS tunneling and using mirrored networking mode.
and netgroup: nis
, for old time's sake
(more constructively, it would be great if there were a header list of the common issues, and if that section linked to something on how to change the networking mode!)
@NelsonMinar if you use mirrored networking mode you can also keep DNS tunneling enabled We only recommend turning off DNS tunneling if you are using NAT networking mode and want to resolve .local names
I will say that the description of dnsTunneling
on https://learn.microsoft.com/en-us/windows/wsl/wsl-config#wslconfig leaves something to be desired. It's basically impossible to tell from the description what it does, such as "make mDNS resolution work", but ideally a more detailed description given that the audience for wsl2 docs likely skews both technically-savvy and curious
Changes how DNS requests are proxied from WSL to Windows
I've executed a wsl --shutdown
after changing %UserProfile/.wslconfig
and still no dice:
OS Build: 22631.4037 Experience: Windows Feature Experience Pack 1000.22700.1027.0
@shaver please make sure to follow the steps from https://learn.microsoft.com/en-us/windows/wsl/troubleshooting#resolve-local-names-in-wsl, section "networkingMode set to Mirrored"
(make sure to update WSL to the latest pre-release build (2.3.17) and do the configuration mentioned in the docs for enabling mdns in Linux)
thank you, I didn't realize I still had .14 installed!
so, it works now, but there's about a 10 second lag in resolution for either IPv6 or IPv4
@CatalinFetoiu should I open a separate bug for the lag? Happy to do so!
@shaver thanks for testing the fix and following up
yes, please feel free to open a separate issue for the delay you observed
I'm still unable to get this to work, despite following the instructions on the Microsoft docs site.
@s73v3r thanks for following up
can you please share the output of sudo strace -ff ping ender6printer.local? please also collect networking logs using https://github.com/microsoft/WSL/blob/master/diagnostics/collect-networking-logs.ps1, using instructions at https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#collect-wsl-logs-for-networking-issues
i ended up with custom code to find ip address. because i have wifi and wifi hot-spot both connected to another pc. i tried mirror mode but i cannot make a ping to global network again. my laptop is window11 home.
IP=$(echo "require('dnssd/lib/resolve').resolve4('nixos12700.local', {interface: 'WLAN'}).then(console.log)" | '/mnt/c/Program Files/nodejs/node.exe')
This solution fixed it for me.
I have the following in my .wslconfig file
[wsl2]
dnsTunneling=false
I even restarted my computer to be sure but I still have issues pinging .local addresses from WSL (it works from powershell). Any other ideas I can try?
WSL version: 2.3.17.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.64
MSRDC version: 1.2.5326
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.22631.4037
UPDATE
I am wondering if the problem is linked to IPV6 because I can directly ping the IPV4 address but not the IPV6 address from WSL and I think the name resolution returns the IPV6 address.
Ping from Powershell using:
Ping from WSL using:
@YAmikep in order to have IPv6 connectivity in WSL you need to enable mirrored mode - you need to add "networkingMode=mirrored" in your wslconfig file
if you do that, you no longer need to disable DNS tunneling in order to resolve .local names
but you need to follow the steps documented at https://learn.microsoft.com/en-us/windows/wsl/troubleshooting#resolve-local-names-in-wsl (install libnss-mdns and configure /etc/nsswitch.conf) to enable Linux to use mDNS queries
let us know know if you have any questions
Thank you @CatalinFetoiu I will try this but I'm also interested in making things work in the NAT mode. Any idea why disabling DNS tunneling does not fix it like it did for some people?
@YAmikep I see, thanks for following up. Please collect networking logs using https://github.com/microsoft/WSL/blob/master/diagnostics/collect-networking-logs.ps1 from the case with NAT mode and dnsTunneling=false and we can take a look
@CatalinFetoiu
Ok thanks, I am going to try to collect these logs.
To make sure I am working with the right setup, though, I'd like to clarify what I need to have .local names resolution work on WSL in theory?
Both avahi-daemon
and libnss-mdns
installed in the WSL distro?
@YAmikep if you are in NAT networking mode, you don't need to install those, but you need to disable DNS tunneling
if you are in mirrored networking mode, you can install libnss-mdns and configure /etc/nsswitch.conf as shown in https://learn.microsoft.com/en-us/windows/wsl/troubleshooting#resolve-local-names-in-wsl
I use Ubuntu 24.04.1 as my distribution and have found the following solution without using avahi-daemon and libnss-mdns.
Make the following adjustments in the files mentioned
dnsTunneling=false
[boot] systemd=true
[network] hostname=wsl generateResolvConf = false
Do not forget to restart the WSL with wsl.exe --shutdown for the adjustments to take effect.
In order to have systemd/resolved use mdns, two more steps are necessary:
DNS=x.x.x.x and multicastDNS=yes must be put into /etc/systemd/resolved.conf and resolved restarted to enable it in general.
it must be enabled per interface. On the command line this can be done with resolvectl mdns eth0 yes
The activation of mDNS for the individual interfaces can then be checked with the command resolvectl mdns.
Thank you @jtgoral. Can you try to put the following in %userprofile%/.wslconfig, then run: "wsl.exe --shutdown" to apply them:
[wsl2] dnsTunneling=false
And see if that solves the issue ?
note: I added just this line and that was enough, ubuntu 24, wsl2, win11pro 24h2
Same for me, got the issue after win11pro 24h2 udpate. Added the line in comment above and now it works again.
I use Ubuntu 24.04.1 as my distribution and have found the following solution without using avahi-daemon and libnss-mdns.
Make the following adjustments in the files mentioned
.wslconfig dnsTunneling=false
/etc/wsl.conf [boot] systemd=true
[network] hostname=wsl generateResolvConf = false
Do not forget to restart the WSL with wsl.exe --shutdown for the adjustments to take effect.
In order to have systemd/resolved use mdns, two more steps are necessary:
- DNS=x.x.x.x and multicastDNS=yes must be put into /etc/systemd/resolved.conf and resolved restarted to enable it in general.
- it must be enabled per interface. On the command line this can be done with resolvectl mdns eth0 yes
The activation of mDNS for the individual interfaces can then be checked with the command resolvectl mdns.
Thank @w00dst0ck for sharing. I found that there's no need to set tunneling to false, my config: (systemd+resolved)
[wsl2]
dnsTunneling=true
# this would enabling dns tunneling at 10.255.255.254
[boot]
systemd=true
# this would enable systemd
[network]
generateResolvConf=false
# this would disable wsl from generating /etc/resolv.conf
# and systemd-resolved would generate its own /etc/resolv.conf
[Resolve]
DNS=10.255.255.254
# this would tell systemd-resolved to use wsl dns tunneling
MulticastDNS=yes
Windows Version
Microsoft Windows [Version 10.0.22635.3061]
WSL Version
2.1.0.0
Are you using WSL 1 or WSL 2?
Kernel Version
5.15.137.3-1
Distro Version
Ubuntu 23.10
Other Software
No response
Repro Steps
ping okno-t320.local does not find okno-t320
Expected Behavior
jacek@okno-galaxy:~$ ping 192.168.68.115 PING 192.168.68.115 (192.168.68.115) 56(84) bytes of data. 64 bytes from 192.168.68.115: icmp_seq=1 ttl=63 time=7.53 ms 64 bytes from 192.168.68.115: icmp_seq=2 ttl=63 time=5.69 ms 64 bytes from 192.168.68.115: icmp_seq=3 ttl=63 time=6.20 ms ^C --- 192.168.68.115 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2005ms rtt min/avg/max/mdev = 5.689/6.472/7.533/0.777 ms
Actual Behavior
jacek@okno-galaxy:~$ ping okno-t320.local ping: okno-t320.local: Name or service not known jacek@okno-galaxy:~$
Diagnostic Logs
No response