Can't resolve ".local" (mDNS) hosnames

[aseering]

I have an existing stock Ubuntu server on my network. Let's say its hostname is "my-server". (The following should work with a stock Mac as well; not sure about Windows servers?)

If I open up a regular Command Prompt, I can do the following:

C:\Users\me>ping my-server.local

Pinging my-server [10.0.0.1] with 32 bytes of data:
Reply from 10.0.0.1: bytes=32 time=3ms TTL=64
Reply from 10.0.0.1: bytes=32 time=1ms TTL=64
Reply from 10.0.0.1: bytes=32 time=1ms TTL=64
Reply from 10.0.0.1: bytes=32 time=1ms TTL=64

Ping statistics for 10.10.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 3ms, Average = 1ms

But from Bash-on-Windows:

bash-on-windows$ ping my-server.local
ping: unknown host my-server.local

For comparison, from a real Ubuntu machine on the same network, I can do:

real-linux$ ping my-server.local
PING my-server.local (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.206 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.138 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.130 ms
(...)

Granted, ping wouldn't work even if it could resolve the name due to #18 , but other tools like curl or ssh would work if appropriate services were running on the server. I'm just trying to post a minimal reproducer.

[aseering]

mDNS resolution on Ubuntu is normally provided by Avahi. But the following doesn't work:

$ sudo apt-get install -y avahi-daemon
(... installs Avahi ...)
$ sudo service avahi-daemon start
 * Starting Avahi mDNS/DNS-SD Daemon avahi-daemon                                                                       Segmentation fault (core dumped)
$ sudo /usr/sbin/avahi-daemon
Found user 'avahi' (UID 106) and group 'avahi' (GID 113).
Successfully dropped root privileges.
avahi-daemon 0.6.31 starting up.
dbus_bus_get_private(): Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
WARNING: Failed to contact D-Bus daemon.
avahi-daemon 0.6.31 exiting.

dbus doesn't work due to #376 .

Unfortunately, I haven't been able to reproduce the segfault while running under strace. Nor under gdb, which just hangs and/or otherwise behaves badly.

[carlpaten]

Oooh, I just hit this one. It was quite a head-scratcher! I'm curious as to whether there's been any progress on this :o

[sunilmut]

On one of the latest builds:

$ apt-get install -y avahi-daemon
$ /etc/init.d/dbus start
$ /usr/sbin/avahi-daemon

Process 588 died: No such process; trying to remove PID file. (/var/run/avahi-daemon//pid)
Found user 'avahi' (UID 112) and group 'avahi' (GID 116).
Successfully dropped root privileges.
avahi-daemon 0.6.32-rc starting up.
Successfully called chroot().
Successfully dropped remaining capabilities.
No service file found in /etc/avahi/services.
*** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***
SO_REUSEPORT failed: Protocol not available
*** WARNING: Detected another IPv6 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***
SO_REUSEPORT failed: Protocol not available
netlink.c: SO_PASSCRED: Invalid argument
on: starting up: iface-linux.c:380: avahi_interface_monitor_sync: Assertion `m' failed.
Aborted (core dumped)

From the output above, we can see few blocking issues here. Those would be; support for the socket option SO_REUSEPORT and SO_PASSCRED for netlink sockets. Support for SO_REUSEPORT requires some work from the core Windows networking team and the WSL team is working with them on that.
SO_PASSCRED for netlink sockets seems entirely in control of WSL and should be trivial. No ETA for either of them yet.

[Plazmaz]

This also makes it impossible to run certain configurations of webpack

[Vipor26]

I hit this while trying to do some work on my pi powered quadrupeds. Back to using my mac terminal.

[scivision]

Lack of Avahi support in WSL makes it difficult to use WSL/WIndows PCs in teaching labs with increasingly ubiquitous Raspberry PI and the like in engineering education.

[sunilmut]

@scivision - I looked into this a bit. As explained previously, there were two blocking issues.

1. Lack of SO_REUSEPORT in WSL (and in Windows in general).
2. Lack of SO_PASSCRED on NETLINK sockets.

After stubbing (1) (because there is no support from Windows networking stack), implementing (2) and few other minor changes, it seems like avahi-daemon is happy.

:~# service dbus start
 * Starting system message bus dbus                                    [ OK ]
:~# service avahi-daemon start
 * Starting Avahi mDNS/DNS-SD Daemon avahi-daemon                      [ OK ]
:~# avahi-resolve-address 192.168.0.52
192.168.0.52    xxxxx.corp.microsoft.com
:~#

I will get the PR out and try to get this in time for Fall Creators Update.

If you look at the avahi-daemon logs (with this change), it still complains about IP_ADD(DROP)_MEMBERSHIP, but that can be taken up as a separate issue. It appears to be functional otherwise, in my limited testing.

[sunilmut]

This should be fixed in 16273

[sgrebnov]

Confirm upgrading to the latest Windows Insider Preview build (1709 build 16288.1) fixed SO_REUSEPORT related issue for me. Thanks

[sunilmut]

@sgrebnov - Thanks for confirming.

I am marking this issue closed. If it persists after upgrading to 16273, please let us know and we can reopen it.

[OhMeadhbh]

So I understand that we consider this bug "fixed," but I was wondering if the functionality described above will ever be implemented. It would be very cool for mDNS / ZeroConf to actually work on WSL.

[therealkenc]

but I was wondering if the functionality described above will ever be implemented

I suspect it already is; just not on port 5353 because there is already something listening there. It is very roughly analogous to asking whether Samba servers will ever work in WSL. They do. But not on port 445. [No one has looked real close though, ref #2664]

[OhMeadhbh]

the title of this issue is "can't resolve '.local' (mDNS) hostnames" and not "can i listen on port 5353."

i'm asking if we'll ever be able to resolve .local (mDNS) hostnames.

[therealkenc]

That's a fair question- I read your "above" ambiguously because this issue morphed immediately into "avahi-daemon dies".

The issue title is likely a Windows ask not a WSL ask. Effectively, your ask is this. If you have a compliant mDNS service that is serving up .local local names correctly in Windows, then it is possible the ping scenario in the OP (ie the client side) would "just work". If it doesn't, that would be a great new issue submission, but it would need a repro with a concise set of CLI repro steps on both the win32 side and the WSL side. That is what I was getting at with the comment about no one (that I am aware of) having looked real close.

[In the interest of completeness, if WSL had its own virtualized ethernet network devices avahi-daemon would work too, in isolation. But that's a different ask.]

[OhMeadhbh]

no. mDNS already works on Windows 10. in fact, my work around is to use cmd.exe to do the resolution with a command like ping -4 whatever.local and then copy the ip address into a bash window.

i assure you, my request is for mDNS name resolution to work on WSL.

[therealkenc]

i assure you, my request is for mDNS name resolution to work on WSL.

And I assure you, if it doesn't work, that would be a great new issue submission. But it would need a repro with a concise set of CLI repro steps on both the win32 side and the WSL side that identified a diverge in behaviour in WSL versus say a Real Linux Ubuntu in a VM connected to the same mDNS service on Windows.

Which no one (that I am aware of) has looked into.

[OhMeadhbh]

scroll up to the top of this page.

aseering gives an example of the behaviour on native linux and then an example on WSL. note that the two systems behave differently despite the same software being installed.

aseering mentions another issue (issue #18), but as I have stated, this is not what i'm talking about. I'm talking about how WSL can't resolve ".local" (mDNS) hostnames. This is independent of the ping utility.

There is also a dependency on dbus working. If it needs to be fixed before this bug can be resolved, then it should be fixed and both this issue and issue #376 should remain open until they are fixed.

Are you really saying this bug was closed because no one can demonstrate mDNS resolution fails in WSL but does not fail under Windows 10? Because this is EXACTLY what this issue demonstrates.

Perhaps someone should look into it.

[therealkenc]

gives an example of the behaviour on native linux and then an example on WSL on native linux and then an example on WSL. note that the two systems behave differently despite the same software being installed.

On Native Linux mDNS services are normally provided by Avahi. As you assured me, your request is for mDNS name resolution to work on WSL, not the Avahi mDNS service. It is not the same software installed. One is Avahi. One is the Windows 10 mDNS service.

There is also a dependency on dbus working

There are no known outstanding issues with dbus in WSL. If you find any problems with dbus, please feel encouraged to open a new issue describing the diverge.

Are you really saying this bug was closed because no one can demonstrate mDNS resolution fails in WSL but does not fail under Windows 10?

I am really saying: that if it doesn't work, that would be a great new issue submission. But it would need a repro with a concise set of CLI repro steps on both the win32 side and the WSL side that identified a diverge in behaviour in WSL versus say a Real Linux Ubuntu in a VM connected to the same mDNS service on Windows.

[kjcole]

My problem (and I'll pour through this and other posts again) is that I have code I've written that works on Linux (Ubuntu and Arch) and Mac OS X. Both the Python code and C# code work fine on Linux and Mac OS X. I am now working with someone else's Windows 10 box, and, wanting all my regular tools , cranked up WSL a la Ubuntu, and cannot get the code to resolve the "*.local" stuff that works in the other two OS's. (If I recall correctly, CygWin did not suffer from this lack of understanding the last time I tried such a thing, but that was many moons ago.)

[davydka]

I really think this issue should be reopened. It would be great if WSL handled mDNS out of the box, or if one simply had to apt install avahi-daemon; sudo service avahi-daemon start
Being able to resolve ".local" network names without copying->pasting ip addresses should be possible.

edit: I'm still seeing this issue on build 17134.286, any assistance is appreciated.

[therealkenc]

Sunil closed this one as spirituality dupe #376 and suggested a new issue be opened on other blockers. The current (as of this writing) well-formed landing zone for avahi-daemon is #3365.

[davydka]

Thank you I will monitor there.

[nabeelr]

It's not just WSL, mDNS .local name resolution stops working on windows x64 randomly throughout the whole OS. It definitely DOES work sometimes but then other times stops. I haven't found out why or when.

I use PowerShell to SSH into a mac box, and sometimes it's .local address works, and other times it doesn't. This is on two different Windows boxes.

Additionally, none of the other non Windows devices have any problem with mDNS .local addresses.

[LuckyGinger]

I have an existing stock Ubuntu server on my network. Let's say its hostname is "my-server". (The following should work with a stock Mac as well; not sure about Windows servers?)

If I open up a regular Command Prompt, I can do the following:

C:\Users\me>ping my-server.local

Pinging my-server [10.0.0.1] with 32 bytes of data:
Reply from 10.0.0.1: bytes=32 time=3ms TTL=64
Reply from 10.0.0.1: bytes=32 time=1ms TTL=64
Reply from 10.0.0.1: bytes=32 time=1ms TTL=64
Reply from 10.0.0.1: bytes=32 time=1ms TTL=64

Ping statistics for 10.10.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 3ms, Average = 1ms

But from Bash-on-Windows:

bash-on-windows$ ping my-server.local
ping: unknown host my-server.local

For comparison, from a real Ubuntu machine on the same network, I can do:

real-linux$ ping my-server.local
PING my-server.local (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.206 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.138 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.130 ms
(...)

Granted, ping wouldn't work even if it could resolve the name due to #18 , but other tools like curl or ssh would work if appropriate services were running on the server. I'm just trying to post a minimal reproducer.

This still doesn't seem to work. OS build 18362.356

[LeviSchuck]

This is still an issue, please reopen.

I am able to use cmd.exe to ping a .local but not WSL.

[strarsis]

@LeviSchuck: Indeed, I have the same issue on latest Windows.
Also see #2664.

[hovissimo]

@sunilmut This is still not working in Version 10.0.17763 Build 17763

[xBelladonna]

Build 18363 has this same problem too, I can't resolve .local names, currently I only use it for SSH, and I'm using a workaround that involves using static IPs and putting the IP as the hostname in .ssh/config. It works, but I'd really rather just have mDNS work.

[ma2shita]

How about trying this?

$ powershell.exe "Resolve-DnsName raspberrypi.local"

powershell.exe can be invoked from bash on WSL.
STDOUT is returned to bash so it can be piped. (e.g. grep, jq (with ConvertTo-JSON in PowerShell))

$ powershell.exe "Resolve-DnsName raspberrypi.local | ConvertTo-Json" | jq -r .IPAddress

[hovissimo]

@ma2shita That works, but it's not a workaround when I'm trying to use Ansible to provision machines, for example.

hovis@Lucca:/mnt/c/Users/hovis$ ping andromeda.local
ping: andromeda.local: Name or service not known
hovis@Lucca:/mnt/c/Users/hovis$ powershell.exe "Resolve-DnsName andromeda.local"

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
Andromeda.local                                AAAA   120   Answer     fe80::b711:58ca:4722:ceda
Andromeda.local                                A      120   Answer     10.0.0.69

[OhMeadhbh]

It also refutes Microsoft's position that "it is impossible to do mDNS in WSL because the WinNT side does mDNS" - if PowerShell can do mDNS, then they should be able to replicate that functionality as a resolver. I am reminded that Microsoft has a long history of favoritism. I mean, it's not surprising that they want you to use WinNT instead of WSL, but they should at least stop saying they're "a Linux Company" or that they support Linux. WSL is a toy, meant to demonstrate the functionality of their hypervisor (which, admittedly, is pretty cool if you want to run WinNT). They clearly have no interest in making a useful product. As much as I groan every time I have to slog through the AWS console, I'm happy to stick with AWS if this is how they support Linux.

[Marandil]

It's understandable why avahi does not work out-of-the-box, but this doesn't mean that the issue is resolved. The issue presented in the first entry could be solved without avahi, e.g. by adding the mDNS entries to /etc/hosts by WSL, or providing the mapping in any other way.

Manually translating hostname to IP will not work if TLS is involved and certificate is issued for the .local domain name. Likewise, SSH may complain.

If not by default, does anyone know if there is a (linux-side) service that can be installed, that interfaces WinNT side to query mDNS resolution?

[strarsis]

Btw., is this issue also on WSL 2?

[therealkenc]

Btw., is this issue also on WSL 2?

avahi-daemon is okay on WSL2 ref #4210 (message). I've been using it myself recently. Whether something like that would (or even should) get rolled into WSL-brand /init I don't know. I suspect (but can't prove) the longer term answer is going to be some kind of support for systemd.

This issue ended up dupe #376 and fixed in 16273, because that was the first (but not the only) blocker on avahi-daemon at the time. Also ref #3365.

[kylemcdonald]

To get .local mDNS hostnames working on WSL 1, I ran the following:

sudo apt update
sudo apt install avahi-daemon
sudo service dbus start
sudo service avahi-daemon start

If I leave out sudo service dbus start then I see:

Starting Avahi mDNS/DNS-SD Daemon avahi-daemon                 [fail]

For me this is only working over IPv4, and not over IPv6.

[jlcd]

To get .local mDNS hostnames working on WSL 1, I ran the following:

sudo apt update
sudo apt install avahi-daemon
sudo service dbus start
sudo service avahi-daemon start

If I leave out sudo service dbus start then I see:

Starting Avahi mDNS/DNS-SD Daemon avahi-daemon                 [fail]

For me this is only working over IPv4, and not over IPv6.

Just to confirm, this works for WSL2, now I'm able to access Windows from WSL.

After running the above steps, the following now works:

$ ping "$(hostname).local"
PING MSI.local (172.19.64.1) 56(84) bytes of data.
64 bytes from 172.19.64.1 (172.19.64.1): icmp_seq=1 ttl=128 time=0.393 ms
64 bytes from 172.19.64.1 (172.19.64.1): icmp_seq=2 ttl=128 time=0.400 ms

[KGrzeg]

After running the above steps, the following now works:

$ ping "$(hostname).local"
PING MSI.local (172.19.64.1) 56(84) bytes of data.
64 bytes from 172.19.64.1 (172.19.64.1): icmp_seq=1 ttl=128 time=0.393 ms
64 bytes from 172.19.64.1 (172.19.64.1): icmp_seq=2 ttl=128 time=0.400 ms

That works as well in my setup, but the WSL can only reach the host machine, no other devices in network.

PS> ping batterytester.local

Pinging batterytester.local [10.0.0.9] with 32 bytes of data:
Reply from 10.0.0.9: bytes=32 time=19ms TTL=255
Reply from 10.0.0.9: bytes=32 time=34ms TTL=255
Reply from 10.0.0.9: bytes=32 time=55ms TTL=255
Reply from 10.0.0.9: bytes=32 time=74ms TTL=255

Ping statistics for 10.0.0.9:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 19ms, Maximum = 74ms, Average = 45ms
PS> wsl.exe
🐧 ping batterytester.local
ping: batterytester.local: Name or service not known
🐧 ping "$(hostname).local"
PING KGrzeg-pc.local (172.19.176.1) 56(84) bytes of data.
64 bytes from 172.19.176.1 (172.19.176.1): icmp_seq=1 ttl=128 time=0.287 ms
64 bytes from 172.19.176.1 (172.19.176.1): icmp_seq=2 ttl=128 time=0.328 ms

The device is pingable via IPv4 address. I have no idea how to fix it.

[techbykyle]

After running the above steps, the following now works:

$ ping "$(hostname).local"
PING MSI.local (172.19.64.1) 56(84) bytes of data.
64 bytes from 172.19.64.1 (172.19.64.1): icmp_seq=1 ttl=128 time=0.393 ms
64 bytes from 172.19.64.1 (172.19.64.1): icmp_seq=2 ttl=128 time=0.400 ms

That works as well in my setup, but the WSL can only reach the host machine, no other devices in network.

PS> ping batterytester.local

Pinging batterytester.local [10.0.0.9] with 32 bytes of data:
Reply from 10.0.0.9: bytes=32 time=19ms TTL=255
Reply from 10.0.0.9: bytes=32 time=34ms TTL=255
Reply from 10.0.0.9: bytes=32 time=55ms TTL=255
Reply from 10.0.0.9: bytes=32 time=74ms TTL=255

Ping statistics for 10.0.0.9:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 19ms, Maximum = 74ms, Average = 45ms
PS> wsl.exe
🐧 ping batterytester.local
ping: batterytester.local: Name or service not known
🐧 ping "$(hostname).local"
PING KGrzeg-pc.local (172.19.176.1) 56(84) bytes of data.
64 bytes from 172.19.176.1 (172.19.176.1): icmp_seq=1 ttl=128 time=0.287 ms
64 bytes from 172.19.176.1 (172.19.176.1): icmp_seq=2 ttl=128 time=0.328 ms

The device is pingable via IPv4 address. I have no idea how to fix it.

I too have this exact behaviour you describe, and I can ping mDNS devices by their IP from the WSL2 instance but nothing by .local.

To add to it my use case is:

On dedicate Ubuntu device i can do:
avahi-browse -d local _http._tcp --resolve -t

Avahi will respond with a list of devices.

Running the same command in WSL2 returns nothing at all.

Anyone have any updates on this?

[dannystaple]

#11022 - seems to be a current incarnation of this, with a work around.